L(_dot_)Wood(_at_)surrey(_dot_)ac(_dot_)uk wrote:
and MD5 is definitely _NOT_ suitable
for anything with the term "integrity" in it.
That depends imo on whether "integrity" is used as a term in a security
context by a security person, or by anyone else. (I am not using the
term as a security person, but have been forced to use it when talking to
security people who have little notion of protection against errors or of
reliability.)
Integrity protection is terminology that is used in the
security&cryptographic area and this defect of rfc-4270 is going
to create misunderstandings.
Yes.
We've actually run into this problem previously, and had to carefully use the
terms when talking to those who focus on terminology used, rather than the
overall point that is trying to be made. This leads to verbal gyrations
and a degree of doubletalk.
'Integrity' and 'protection' do have meanings outside security, and were used
long before their specific use in a security context (cf database integrity,
system integrity, even integrity protection in chemical plants). From context
here and the rest of the sentence, it's imo clear that reliability is what
is being referred to.
I've been focused so much on security over more than a decade that
myself I am actually unfamiliar with uses of "integrity protection"
in a sense that is _not_ security-related.
Although the attacks against MD5 published so far are practical only
for creating collision pairs, there has not been published a practical
preimage attack against MD5. But the practical collision attack alone
is devastating for several integrity protection usage scenarios.
see this here: http://www.win.tue.nl/hashclash/rogue-ca/
Open the "Certificate Manager" of a newer Firefox/Mozilla browser
(Menu: Tools->Options, Section "Advanced", Tab "Encryption",
Button "View Certificates", Tab "Authorities")
Under "Equifax Secure Inc." you will probably find a CA certificate
labelled "MD5 Collisions Inc. (http://www.phreedom.org/md5)"
signed by Equifax Secure Global eBusiness CA-1, expired in Sep-2004
and that cert is pre-configured to be _not_ trusted for any purpose.
(a somewhat non-obvious way of blacklisting a certificate).
The MD5-based RSA signature in that cert still contains the original
MD5 checksum that Equifax calculated when it issued a different
(but fairly similar) end-entity cert with a different validity.
This fake CA certificate was created with the help of the MD5 collision
attack, not by a preimage attack.
But if you look at the purpose / usage scenario of the MD5 hash here,
then it is about some SSL client ("Bob") receiving an assertion of identity
for a server "i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org"
integrity protected by an RSA-encrypted MD5 hash from Equifax ("Alice"),
which can be successfully substitued by an attacker ("mallory") with
an intermediate CA certificate (plus an end-entity cert for any arbitrary
server created at will by mallory), and the Equifax-signed
MD5 checksum does not protect against this substitution, because
the fake CA cert has the exact same MD5 checksum as the cert
originally issued by Equifax.
The details are described in section 5.3 (but only 5.2 has an anchor tag):
http://www.win.tue.nl/hashclash/rogue-ca/#sec52
Admittedly it isn't trivial to use a collision attack to do achieve
something that normally requires a preimage attack, but it is going to
be possible much more often than you will want it to for a creative
attacker. And a lot of PDUs that are digitally signed these days
provide wiggle room for "binary random stuffing" necessary to precompute
collision attacks and will be ignored by recipients. Especially in
protocols using ASN.1.
According to this report:
http://www.eff.org/files/DefconSSLiverse.pdf
there appear to exist almost 1500 "trustworthy" SSL CAs, and
and attacker only needs to find a single one among them where
such an attack still works...
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf