[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PGP Keyserver Synchronization Protocol

William Geiger wrote:

>>Once the client has downloaded a key from the server and updated it's data
>>base, if the hashes are still different then the client must have the
>>"newer" data.

Where did the client get the ""newer data"" from ??
Is not the client updating  himself from a master database that should have
the latest info ??

David Gaon

-----Original Message-----
From: William H. Geiger III [mailto:whgiii@openpgp.net]
Sent: Wednesday, June 23, 1999 10:48 AM
To: Tony Mione
Cc: pgp-keyserver-folk@flame.org; ietf-open-pgp@imc.org
Subject: Re: PGP Keyserver Synchronization Protocol

In <Pine.GSO.4.02A.9906222239500.23439-100000@hardees.rutgers.edu>, on
   at 10:46 PM, Tony Mione <mione@hardees.Rutgers.EDU> said:

>> Overview:
>> 	The synchronization process involves several steps:
>> 	Generation of Hash Tables
>> 	Exchange of Hash Tables
>> 	Comparison of Hash Tables
>> 	Exchange of Keys
>> In this process one database is initiating the synchronization (client)
>> while the other is the receiver of a synchronization request (server). To
>> start the process the client will create a hash table of his database
>> he will request a hash table from the server. When the client receives
>> server's hash table he will compair it with his own and generate 3 lists:
>> 	#1 All Keys that are on the server but not on the client
>> 	#2 All Keys that are on the client but not the server
>> 	#3 All Keys that are on both client & server but have different
>> The client will then request from the server all the keys in list #1 & #2
>> and add thoses keys to it's database. Once this is done the client will

>I'm a bit confused here. List #2 contains all keys on the client that are
>NOT on the server. How can the server send such a list? 

The server sends the entire hash list of all it's keys. The client, by
comparing the hash list it has generated locally, generates list #1, #2,

>IF you meant list #3, how can you tell which keys from the server are
>actually newer than the client keys. Just because they are different
>does not mean that the server (rather than the requester) has the most
>up-to-date copy of the key.

Yes, that text should have read: "all the keys in list #1 & #3"

There is no efficient way to determine who has the most up to date version
of a key. Hopefully, with periodic server synchronization, #3 should be a
small list.

>> generate a new hash table for his database and compair it to the hash
>> table he has from the server. He should now only have 2 lists:
>> 	#1 All Keys on the client but not on the server
>> 	#2 All Keys on the client & server but have different hashes
>> The client should then send the server all keys that are in the 2 lists.

>Same comment about who really has the most up-to-date key.

Once the client has downloaded a key from the server and updated it's data
base, if the hashes are still different then the client must have the
"newer" data.

>> Calculating Hashes:
>> 	It is important that when calculating the hash of a key that it be
>> in a specific order as to guarentee that the identical key in two
>> different databases has the same hash. The following order of operation
>> for calculating the hash is:
>> 	Primary Key
>> 	SubKeys Sorted by KeyID
>> 	Signatures Sorted by Signing KeyID
>> 	UserID's Sorted Alphabeticaly
>> PhotoID's & X509 signatures are 2 issues that need to be looked into.
>> Unfortunatally the specs for neither of these packets have been released
>> by NAI. For right now I recomend that any propritary packets *not* be
>> in the key hash calculations.

>Does it really matter if you do not know the internal packet format as
>long as you know where the packet ends? Hashing is simply mixing together
>a stream of octets and so I do not believe the 'format' makes much of a

Well the problem of unknown and/or undocumented packet formats is that of
sorting. For two different systems to come up with the same hash for an
identical key, they must calculate the hash in the same manner. I have
outlined above how to do this with known OpenPGP packets. It is difficult
to set up similar procedures for packets who's format are unknown.

William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)