-----BEGIN PGP SIGNED MESSAGE-----
In
<3(_dot_)0(_dot_)5(_dot_)32(_dot_)19980717110808(_dot_)00971d00(_at_)popd(_dot_)ix(_dot_)netcom(_dot_)com>,
on 07/17/98
at 01:08 PM, bill(_dot_)stewart(_at_)pobox(_dot_)com said:
* Lindsay Mathieson wrote:
As far as I understand it, it is impossible to guarantee a unique Key ID &
fingerprint, as they are hash's of the key material, which implies the
possibility of a hash collision, highly unlikely maybe, but still possible.
I'd call 2**-128 impossible, and 2**-64 birthday collisions close to
impossible. But 64-bit KeyIDs lead to birthday collisions with about
2**32 keys, which _will_ happen, and then there's the problem of the user
interfaces (at least on the key servers) only showing the user 32 bits of
key instead of 64 (which is not only susceptible to birthday collisions
but 0xdeadbeef attacks, though they're less useful than they used to be.)
Keyservers especially need to be able to cope with duplicates.
At 02:35 PM 10/29/1997 GMT, Lutz Donnerhacke wrote:
That's why my proposal causing this controversy was/is to define it not
unique.
Sounds good.
Hi Bill,
Replying to a year old post? Took me a while to dig up the reference
articles :)
I think that it is quite obvious that any large scale PGP DB will need to
implement local UID's for all of the keys and use that for reference. The
only other alternative would be to deny duplicate keyid's into the
database.
Inbound processing is not that much of a problem as one just check all
matching keyid's until one is found that verifies the signature. It would
probably be a good idea to flag any duplicate keyid's in the DB and make
mention of that to the user whenever that key is used.
Where things get interesting is in the outbound processing. :)
The best way to handle this is with the use of a default key table. Now
first off it is my strong opinion that a table is required that links
e-mail addresses to specific keys. This is to resolve conflicts that arise
when:
- -- More than one key has the same userID
- -- e-mail address used is not contained a userID for the corresponding key
I also use this table for listing address that should not be encrypted
ever. This is mostly for mailing list addresses.
I also list addresses where addresses should not be signed. This is mostly
for majordomo's and such that get upset if PGP sigs are in the body of a
message.
I am also working on a remailer interface so I will be adding a flag to
the e-mail addresses where all messages to that address should go through
a remailer chain or should not if the user has his system set to send
everything through a remailer chain.
AFAIK I am the only one who is addressing these issues in their software.
Currently my links between e-mail address and keys are based on the 64bit
keyid as I do not allow duplicate keyid's at this time. This can easily be
expanded to allow the handling of duplicate keyid's by linking to UID's
rather than the KeyID.
I also plan on using this table for allowing the end-user to override the
default flags in the public key self sigs (don't worry this is just for
the power users not the average joe sixpack who are only concerned with
point 'n click).
- --
- ---------------------------------------------------------------
William H. Geiger III http://users.invweb.net/~whgiii
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://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
Tag-O-Matic: Turn your 486 into a Gameboy: Type WIN at C:\>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNa+ov49Co1n+aLhhAQEaCQP/WTtw0292pLTmqElJPI2QKm9SYDGDMjCk
kfC23nk4811FlUe8G0liYI3Xwte7h4VJOSeUn7CL6jkpfObWDOjUw78jGNV2iTqQ
+rxU8FIwl0hcn/bZ7X3GkTUHW3+4wAQEKgQVkXjRKWvG46ZQtHHOSKz/zjQCIBBS
qHOJ4BHo0GM=
=82T9
-----END PGP SIGNATURE-----