Olle Mulmo wrote: > Seems to me that a CA can nullify this attack by choosing a serial number or RDN component (after all, a CA should vet the DN and not simply sign what's in the PKCS#10 request), such that the public key does not end up at an "appropriate" DER-encoded offset in the > certificate. Or am I completely lost?
Yes, there seem to several possibilities to defend against this kind of attack in a real world scenario. Modifying the subject DN in a way un-predictable by the attacker is one of them. For Benne's attack it would be enough to modify its length, so that the public key doesn't get to the required offset. I would like to have a general way to fend off collision attacks on certificates. To this end I propose that the CA generates the certificate serialNumber in a way that cannot be guessed. Some CAs are already doing this, I guess mainly to prevent people from seeing how many certs they issue. There are several advantages of using the serialNumber: * it has no semantics that we might break, as long as we make sure it stays unique * it is one of the first items in a certificates, before any content an attacker might control * its no problem to make it e.g. 128 bits long By putting an un-guessable value in the serialNumber, the attacker is faced with a similar problem as with a HMAC, which people believe are not affected by the known collision attacks. For this reason I believe with un-guessable serialNumbers, we should be safe to use a hash function, which is not collision resistant, as long as it is 2nd pre-image resistant. Its rather easy to implement un-guessable servialNumbers: * use a cryptographically strong PRNG (and keep the seed secret) or TRNG * encrypt a counter with a block cipher (and keep the key secret) Best regards, J�rg --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
