Hi Joerg, It's true that our 'attack' assumes that the attacker has sufficient control over the CA, in particular over setting DN's, serial numbers and the validity period. Yet I have a few remarks on this.
A relying party cannot find out from the certificate alone whether it has a "twin sister" or not. The fact that there is a random-looking serial number doesn't help you there. A newly issued certificate based on MD5 should not be trusted anymore anyway. The only reasonable measure against collision-based attacks is to declare MD5 dead. It's better to bury it than to try keeping it alive. I have nothing against randomized serial numbers. But your security should be based on better ideas. And it's just as easy to avoid broken hash functions. Grtz, Benne de Weger > -----Original Message----- > From: Joerg Schneider [mailto:[EMAIL PROTECTED] > Sent: vrijdag 11 maart 2005 11:52 > To: Olle Mulmo > Cc: Weger, B.M.M. de; cryptography@metzdowd.com > Subject: Re: Colliding X.509 Certificates > > 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]
