Re: [Sks-devel] exchange of ideas

[brent s.]

Whoops, sent a direct reply instead of to the list. Pasted below.

On Mar 22, 2019 23:20, fuat <address@hidden> wrote:

I thought it was more comprehensive. 

Let me explain. 

A text file, html file, and .asc file are not dangerous to the server. 

Which is what I assert in my first reply, yes.

The attacker cannot harm the server with the text file. can only read. 
but sks database is very often corrupted. If there is an error in 
writing a file, only that file is corrupted. 

Hasn't happened to me in the two? Three? Years I've been a public pool member. DBs also have a more robust journaling than flat filesystem backends, which you're ignoring.

The content of a text file from the internet is quick to reach. 

Do you plan om doing a google search against a BASE64 snippet instead of a key attribute? I fail to understand the relevance of this.

all keys or over 500 keys do not overload the server unless requested 
at one time. already sks software also outputs single key. 

Unless a recon peer, or a multiple-match search which will return references to other keys.

The database occupies only 20 percent less disk space and the search is 
slightly faster than 20 percent. 

sks KDB 18G 
5.500.000 readeable .asc files 25G 

however, instead of remaining dependent on a single system for such a 
difference, it would be more flexible and diverse to work with 
different programs that achieve the same results and do the same. 

No, it wouldn't, because there is no RFC for this. There is for OpenPGP, which is precisely why it's used.

only molds are decided jointly, and each program produces the 
appropriate output to the same pattern. 

it doesn't matter if you get to an address with firefox, opera or 
chrome, the important thing is that the address you enter is the same. 

Again, your proposed method breaks PGP/GPG, which is the entire reason the SKS pool exists.