On Mon, Dec 22, 2008 at 09:58:07PM -0800, David Schwartz wrote:
>
> > - Don't choose algorithms for security, choose protocols for
> > security.
>
> That sounds completely backwards to me. 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.
>
> For example, suppose I need to synchronize files across a network. The first
> thing I would do is ask what algorithms are suitable. Is compare by hash
> okay? Do I need encryption? Do I need compression? Then, with a list of
> algorithms that suit my requirements, I can look at protocols that implement
> them.
>
> You can't look at the protocols first. For example, SSL can be used with
> many different algorithms. So can SSH. So asking, "does SSL meet my
> requirements" isn't really even possible without recursing into the
> algorithms it supports.
We'll have to disagree I am afraid. TLS is a channel-security protocol
and as in the quote about democracy, TLS is the worst form channel
security, except for all the rest.
So, yes, indeed, you'd better choose TLS first, and only then if at all
worry about whether it is is using AES, 3DES or RC4, ...
If I catch application developers explicitly selecting ciphers and bit
strengths, they're off to "security re-education camp". If they
choose TLS for channel security, set the cipherlist to something
sensibly generic like:
"DEFAULT:!LOW:!EXPORT"
and implement peer certificate checks correctly (far more likely to be
broken than the crypto) they are a rare find and get high praise.
> > - The right protocol will have a sensible set of algorithms to
> > go with it, in some cases choose the appropriate subset of
> > parameters within the protocol to yield the right security,
> > performance and interoperability trade-offs.
>
> That's, largely, what makes it the right protocol.
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).
> If we want secure compare
> by hash, then almost any sync protocol that uses SHA-256 will be fine but
> almost any that uses MD5 will not. Why? Because SHA-256 is good for compare
> by hash and MD5 is not. Any protocol that's not brain-damaged that uses
> SHA-256 will work, and any that uses MD5 will not.
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:
http://www.schneier.com/book-practical-preface.html
Security is only as strong as the weakest link, and the mathematics
of cryptography is almost never the weakest link. The fundamentals
of cryptography are important, but far more important is how those
fundamentals are implemented and used. Arguing about whether a
key should be 112 bits or 128 bits long is rather like pounding
a huge stake into the ground and hoping the attacker runs right
into it. You can argue whether the stake should be a mile or a
mile-and-a-half high, but the attacker is simply going to walk around
the stake. Security is a broad stockade: it's the things around the
cryptography that make the cryptography effective.
If leaving MD5 enabled improves interoperability, leave it enabled...
Yes, once you have a decent protocol, disable legacy symmetric ciphers
weaker than ~80 bits (no 40-bit "export" ciphers, no single-DES),
but choose the protocol that addresses the right security model (say
secure transport) and don't sweat the algorithms too much, the protocol
designers should have taken care of that.
This advice is of course for application developers, not cryptographers.
Still, somehow, I don't think we're likely to reach consensus, over
and out.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
