On Wed, Dec 31, 2008 at 11:59:50AM -0800, David Schwartz wrote:
>
> Victor Duchovni wrote (ironically, just a week ago):
>
> > No, it is the protocol design (how all the pieces fit together), not the
> > specific algorithms that make it secure (yes the pieces have to have
> > the right general properties, but this is secondary).
>
> I can't resist pointing out how today's news has made my point:
> http://www.win.tue.nl/hashclash/rogue-ca/
No it did not. In the context of TLS, RC4-MD5 (for example) continues
to be as secure as before.
> MD5 has the right general properties, but the protocol design failed. Why?
> Because it used an unsuitable algorithm.
The TLS protocol did not fail, what failed is the X.509v3 protocol where
algorithm choices are not made by SSL users, rather the poor choices
were made by CAs, who should have known better, and in any case have
largely phased out MD5, with Verisign (reportedly) just one month away
from completing their migration to SHA-1.
> > MD5 is (still) vastly stronger (no known second-preimage attacks) in most
> > applications than the weakest parts in real security systems. Spending
> > time choosing between MD5 to SHA1 is in most cases a waste of time. Sure,
> > use SHA1, it is best practice to do so, but this is extremely likely to
> > have any positive impact on the security of the system in question:
>
> You still think so?
Yes. There are still no second pre-image attacks. Of course if a protocol
requires lack of chosen-prefix attacks (e.g. X.509 and only when the
prefix of the CA certificate is predictable) then said protocol must
avoid MD5.
> >> When we have a set of security requirements, the first thing
> >> we do is select the algorithms that meet those requirements,
> >> then we look for protocols that implement them.
>
> SSL uses MD5 for compare-by-hash. MD5 is broken for compare-by-hash in a
> situation where an attacker knows the correct input and can choose his own
> input.
No, MD5 is broken when an attacker gets to *choose* two inputs and get
you to sign one of them. It is not broken when the attacker does not
choose the signed input. MD5 continues (best current research) to be
safe for use with SSL. The validation of X.509 certs is an ancilliary
protocol where signatures on non-root CA certs should not be MD5.
> My point is not that this particular break is the end of the world or that
> people should disable MD5 right now. Victor was certainly right when he
> said:
>
> > If leaving MD5 enabled improves interoperability, leave it enabled...
>
> My point is that the first think you should do after figuring out your
> threat model and requirements is investigate the algorithms that can defeat
> that threat model and meet those requirements. Then look for a protocol that
> implements those algorithms.
No, but you forget we won't agree. I don't believe that non-experts can
come remotely close to choosing algorithms well, but they can choose from
a menu of protocols, given a reasonable description of which protocols
are alleged to solve which problem.
TLS: channel-security
PGP or S/MIME message-security
AES-XTR disk encryption
...
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
