[17053] in cryptography@c2.net mail archive
Re: Colliding X.509 Certificates
daemon@ATHENA.MIT.EDU (Joerg Schneider)
Sun Mar 13 14:43:28 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Fri, 11 Mar 2005 11:52:00 +0100 (CET)
From: "Joerg Schneider" <js@joergschneider.com>
To: "Olle Mulmo" <mulmo@pdc.kth.se>
Cc: "Weger, B.M.M. de" <b.m.m.d.weger@TUE.nl>,
cryptography@metzdowd.com
In-Reply-To: <cb463d00d76fe24f01ab7ebf2e86489f@pdc.kth.se>
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@metzdowd.com
