In <slrn64oq3v(_dot_)m0(_dot_)lutz(_at_)taranis(_dot_)iks-jena(_dot_)de>, on
10/21/97
at 08, lutz(_at_)taranis(_dot_)iks-jena(_dot_)de (Lutz Donnerhacke) said:
* William H. Geiger III wrote:
Well I think we should have had some disscussion on this. This really
plays havok on keyring lookups & management if keyID is nolonger unique.
If this is the tact to be taken then we should look at the encrypt & sig
packets and find a unique identifier to use with them perhaps just put the
whole fingerprint there. Without a unique identifyer there will be a
marked decrease of performance in PGP operations in areas where PGP
performance is poor to begin with.
I do not know how to deal with key ID attacks, birthday phenomena, and
user provided parts of the key/user ID without defining the key ID as not
unique.
A local database does not depend on the uniqueness of the global key ID.
But we know, that if it tries to depend on it, it is attackable.
Normally a key database is small. (large databases are still very slow in
current versions of PGP due to bad implementation) So only a few keys has
to be tried. Normally only a single key has to be tried. If 0xdeadbeef
keys are removed locally, this is even true for attacked enviroments.
Well the way I see it we have 2 possabilities for duplicate keyID's:
1) Collision. Does anyone know what the probability of 2 users generating
2 unique keys with the same keyID? If this number is high then perhaps we
should look at either using the fingerprint in the PGP packets or
providing additional info in the packets to provide uniqueness.
2) Diliberate Attack. We know of the common attacks aginst the keyID &
Fingerprint with the PGP 2.6.x keys. Are the DSS/DH keys also open to such
attacks? Is it realy wise to allow these keys to be added to the keyring
in the first place or should the user when confronted with duplicate
keyID's be required to take futher action?
I can see where in a Public keyserver environment it is easier to allow
duplicate keyID's to prevent a DOS attack with a spoofed key. For a
corporate keyserver or a local keyring I am not sure if allowing these
keys into the database is a wise thing.
I may be wide off on this one but it just seems to be a bad design
approach to allow non-unique identifyers in the PGP packets and then try
every key that matches it.
--
---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~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 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
---------------------------------------------------------------