[17064] in cryptography@c2.net mail archive
RE: Colliding X.509 Certificates
daemon@ATHENA.MIT.EDU (Weger, B.M.M. de)
Tue Mar 15 10:37:53 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Mon, 14 Mar 2005 10:48:47 +0100
From: "Weger, B.M.M. de" <b.m.m.d.weger@TUE.nl>
To: "Joerg Schneider" <js@joergschneider.com>
Cc: "Olle Mulmo" <mulmo@pdc.kth.se>, <cryptography@metzdowd.com>
Hi Joerg,
> My concern is not MD5, its SHA-1. I don't see that we can get rid of=20
> SHA-1 in certificates in the next 5 years:
> * None of the alternatives is widely implemented today.
> * For controlled environments like in-house applications you might be=20
> able to switch earlier (0-2 years).
> * In open environments like inter company S/MIME or public facing SSL=20
> servers it will take years before you can assume that people=20
> are able to=20
> verify non SHA-1 certs.
> * For CA certificates you'll have to add more years (not to=20
> speak about=20
> those CA certs with notAfter=3D2038).
>
> From this perspective it makes sense to think about=20
> operating a CA with=20
> a broken hash function, I believe.
> * Technically SHA-1 is broken today.
> * I don't fear that anybody might attack my CA based on the=20
> attack known=20
> today.
> * But given the progress in the last year I personally expect the=20
> attacks on SHA-1 to get more practical.
It makes sense to do a risk analysis, based on a.o.
* how critical is the particular application to the business
* what threats are there (who might try something bad)
* what's the user community (in-house or the entire world or
something in between)
and then accept a certain residual risk of continuing the use of
'broken' hash functions for some more time.=20
At the same time it is wise to start deploying better hash functions.=20
I hope the Microsofts and Suns and <name your favourite software
factory> of this world are working on this right now. It's clear that=20
this is going to take a long time and cost a lot of money. We're very=20
lucky that the present attacks are still to a large extent theoretical=20
in nature, and do not (yet) lead to realistic attack scenarios (at=20
least we couldn't think of one, and we haven't seen anybody else=20
coming up with one).
The main lesson to be learnt here is that we have made our systems=20
too dependent on a few cryptographic primitives only; much more
flexibility is needed. One of these days some smart person may come=20
up with a real attack on <name your favorite cryptographic primitive>,
then you cannot afford two years to change your systems.
So I still think that the message we should send into the world is
to phase out MD5 now, and SHA-1 a.s.a.p. (NIST says: by 2010, that=20
sounds very long to me). If you cannot do that for practical reasons,=20
then that's your risk. When you accept that risk, that's fine with me.
=20
Apart from that I've never understood why there are CA certificates=20
with such incredibly long lifetimes. That's simply asking for trouble.
> > A relying party cannot find out from the certificate alone whether
> > it has a "twin sister" or not. The fact that there is a=20
> random-looking
> > serial number doesn't help you there.
> That is true, and its certainly not nice. But I think the=20
> real concern=20
> of the relying party is not specifically about certificates with the=20
> same hash, its about
> * the correctness of the contents (name of private key holder=20
> etc.) and
> * the existance of other certificates issued to same key but=20
> different=20
> name, which might be used to repudiate signatures, e.g.
>=20
> The relying party always needs to trust the CA on those two=20
> properties,=20
> as the CA can easily issue certs with incorrect conents, it=20
> doesn't need=20
> hash collisions for that.
>=20
> My question is: Can a CA prevent "twin sisters" from coming into=20
> existance by using my proposed procedure?
With current knowledge the answer is: yes. Randomized serial numbers=20
will be sufficient. And indeed: a CA doesn't need hash collisions
to do real damage.=20
Grtz,
Benne
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
Technische Universiteit Eindhoven=20
Coding & Crypto Groep=20
Faculteit Wiskunde en Informatica=20
Den Dolech 2=20
Postbus 513=20
5600 MB Eindhoven=20
kamer HG 9.84=20
www: http://www.win.tue.nl/~bdeweger=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
=20
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
