"No-Keyserver" (and other) flags on keys

[John Clizbe]

Dan Mahoney, System Admin wrote:
> 
> I'm also not aware of how servers synchronize, but if it's a different 
> protocol than the standard single-key-request protocol, then there's an 
> easy metric to say "don't hand out keys with this flag via this protocol".

For SKS (taken from the current SKS project page,
    http://code.google.com/p/sks-keyserver ):

+> The foundation of SKS is an efficient algorithm for reconciling remote data
+> sets. That algorithm is described in the following papers:
+>
+>     * Set Reconciliation with Nearly Optimal Communication Complexity[0]
+>     * Practical Set Reconciliation[1]
+>
+> You can find the (somewhat limited) documentation here[2].
+>
+> [0] http://ipsit.bu.edu/documents/ieee-it3-web.pdf
+>
+> [1] http://ipsit.bu.edu/documents/BUTR2002-01.ps
+>
+> [2] http://code.google.com/p/sks-keyserver/wiki/Documentation

It's pretty safe to say SKS doesn't look at any key contents when exchanging
keys. Reconciliation only ensures that two copies of the data have the same
member bits, and fairly rapidly at that (2.8 million keys/4.3GB key material
compared up to 6 times per minute).

-- 
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 499 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100628/f5489878/attachment.pgp>