--4ndw/alBWmZEhfcZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable * Povl H. Pedersen (popeat_private) [000308 11:39]: > They do NOT have the same keypair, as "John Smith" just like me has=20 > an old "silver" PGP 2.5 key, while Mike Evans has a new "gold" key,=20 > meaning he uses one of the never non-copyrigthed algorithms and=20 > keyset of a different size. Then, they should not be able to create valid signatures for each other. The only way to create a valid signature for a given public key is to use the one private key that corresponds to this public key. Therefore to forge a signature the key pairs have to be equal. In your first mail you said that the signature of one user can be validated with the others key. This is a extremely strong hint for the=20 assumption that both keys are identical.=20 If both keys are different in algorithm, say key one is using RSA and key two is using DH/DSS, chances that both produce the same signature are too small to believe it.=20 > The keyID is only 8 hex digits =3D 4 bytes =3D ~4.000.000.000 different= =20 > keys, and there are probably more than this one case of 2 users with=20 > same keyID. As said, the key id is calculated from the key. A V3 key id consists of the lowest 64 bits of the public modulus ot the RSA key, whereas a V4 key id equals the lowest 64 bits of the fingerprint of the whole key. However, the OpenPGP standard (RFC 2440) explicitely says that: "Note that it is possible for there to be collisions of key IDs -- two different keys with the same key ID. Note that there is a much smaller, but still non-zero probability that two different keys have the same fingerprint." (page 53) There is another note in this document that talks about problems with key IDs: "V3 keys SHOULD only be used for backward compatibility because of=20 three weeknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collusions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms." (page 36) > The problem is the keyserver not listing all keys entered that=20 > computes to the same keyID, to let the user doing a lookup see that=20 > there is multiple registered users with the same key. As you see, this is known and discussed in the standard. I don't see, why there is any security problem here.=20 If there is a collusion in key IDs and the key server does only list the other key, the person who uses this key to verify a signature will get a notification about an invalid signature. This is not really bothering. > Or they should start using the fingerprint instead, which is much longer. When signing a key or deciding whether to trust a key, you _must_ _always_ verify the fingerprint. However, for finding keys the usage of the shorter key ID is sufficient, since this is only used to help users to find the correct key. As the key ID of V3 keys is easy to forge, it is not allowed to use the key ID for anything other as to help the user to pre-select the key set that might contain the key he is looking for. Ciao, Tobias --=20 Dipl. Inform. Tobias Haustein Department of Computer Science IV, Aachen University of Technology Ahornstr. 55, D-52056 Aachen Phone +49 (241) 80-21417, Fax +49 (241) 8888-220 E-Mail hausteinat_private-aachen.de Web http://www-i4.informatik.rwth-aachen.de/~haustein/ --4ndw/alBWmZEhfcZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: kLYzxUL9aH5IkYOZG1oMRL5MXGRfWYxX iQEVAwUBOMY/Sxs02tO3FOYBAQGrZwf+I32o8EBLRa+45Gf7KQhyb6TcTwo3a2yY bP2oAyOYp9HY+3ZjZKzLBdRCQXd2L40zhdQVHq0/EzT8XdQY4AkPp9iDMj3WaY+g URo0xjBZnLtoH6YhvM6xyLX6CuiV5GilYo1iPaXg+eAsv5dqDr2lCO/A/liuQcS6 jFfmbma+1Op/qlaLrXzM60O/gAdy1jGEhpshLuPNmo0OHUULH0nKNXJ6gw0zRPFr kXYBC4yWMJUmQYG383Vr4XqT/RIGk2afO4eFdPdJ3rxo0rndy6ddCMF0uCokJd59 uo+necnSILlNR0OjUjwgQDoEPLVKNtkfvkHLRqQ7lejG3yX40VWFfg== =OGvj -----END PGP SIGNATURE----- --4ndw/alBWmZEhfcZ--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:39:13 PDT