Colliding X.509 Certificates

Weger, B.M.M. de b.m.m.d.weger at
Fri Mar 11 06:11:35 EST 2005

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.

Benne de Weger

> -----Original Message-----
> From: Joerg Schneider [mailto:js at] 
> Sent: vrijdag 11 maart 2005 11:52
> To: Olle Mulmo
> Cc: Weger, B.M.M. de; cryptography at
> 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 majordomo at

More information about the cryptography mailing list