
Cryptographic Right Answers - cperciva
http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html
======
tptacek
First, I'll quibble with some of these recommendations --- even though Colin
(and Alex Ross, and probably Bruce) is more qualified to have an opinion here.

For instance, CTR+HMAC is a weird recommendation. Not because of speed (though
HMAC does pessimize speed) and not because of cryptographic strength, but
because it introduces another moving part in your design. Colin can deal with
the junction between plaintext, ciphertext, and HMAC, because this is mostly
all he thinks about. You can't.

A simpler recommendation would have been to use CCM or EAX mode. These have
the advantages of being NIST standards-tracked and heavily vetted, and of
providing _both_ authentication and encryption in the same construction. If
your libraries are good, you get both these features just by switching the
name of your block mode.

Second, I'll quibble with the content of the post: these recommendations are
exactly what Nate was talking about in his Yahoo talk about how bad
cryptographic guidance has gotten. Key size and hash function selection (as
long as you're not using MD5) are _the least important_ design considerations
you have.

Here's a design consideration this post doesn't even touch on: renewability.
How do you safely design a system so that your selection of algorithms, modes,
and key sizes isn't set in stone? Because if you don't get that right today,
what you inevitably do to handle it 2 years from now is going to be a
vulnerability.

Finally, a real concern about the structure of these recommendations: telling
people to keep group negotiation out of Diffie-Hellman protocols is fine --- a
good recommendation, since there's a really scary sounding, really easily-
exploitable vulnerability that eliminates. But that's --- I think --- the
_only place_ in this post where Colin actually addresses something that
actually does go wrong in crypto protocols.

If you follow all of Colin's recommendations here from scratch in a reasonably
complicated, and you have never found a crypto vulnerability or fixed two
reported crypto vulnerabilities, I will bet $500 that you end up with a broken
system. Colin won't. But you will.

~~~
cperciva
_CTR+HMAC is a weird recommendation_

Encrypt-then-HMAC has been a widely used standard for the past decade, and has
been extensively studied.

 _A simpler recommendation would have been to use CCM or EAX mode._

AES-CTR and HMAC-SHA256 are far more simple than AES-CCM or AES-EAX. AES-CTR
plus HMAC-SHA256 is also far more secure against side channel attacks, and has
the advantage of allowing you to separate authentication from encryption --
useful if, say, you want to include some unencrypted data in an authenticated
packet as well.

 _Key size and hash function selection (as long as you're not using MD5) are
the least important design considerations you have._

I didn't mean to imply that all of the issues I mentioned were very important.
My selection was more or less done on the basis of "what questions have people
asked me recently?"

 _If you follow all of Colin's recommendations here from scratch in a
reasonably complicated, and you have never found a crypto vulnerability or
fixed two reported crypto vulnerabilities, I will bet $500 that you end up
with a broken system._

That's probably a safe bet. I think it would be an even safer bet if you made
it with someone who _didn't_ follow my recommendations.

~~~
tptacek
Your first point, about how well-studied HMAC is vs. CCM, is one of those
points that makes a lot of sense in an academic context and much less sense in
practice. In an academic context you assume both implementations are sound. In
a practical context, you have to consider how likely it is that the
implementor is going to make unsound choices.

The same goes double for your second point. Yes, if you have to implement the
MAC yourself, you clearly want to use HMAC rather than trying to get CBC-MAC
right. But if you're in a place where you have to implement your own MAC, you
are doomed for a bunch of other reasons. CCM is preferable to HMAC because
it's likely you're going to simply be able to change CTR to CCM and have it.

~~~
cperciva
_Yes, if you have to implement the MAC yourself..._

I didn't say anything about implementing the MAC yourself. _Someone_ has to
implement it, though -- and no matter who writes the code, HMAC-SHA256 is far
more likely to be right and not leaking data via side channels than CBC-MAC
is.

~~~
tptacek
Bespoke CBC-MAC is an almost-certain disaster. HMAC-SHA256 has some obvious
implementation failure modes. It's less easy to see how someone screws up
typing "CCM" into their library.

The point is that there are already shrink-wrapped AE constructions (like CCM
or EAX) that you can pick up off the shelf and use; HMAC designs are more
likely to be bespoke.

~~~
cperciva
_It's less easy to see how someone screws up typing "CCM" into their library._

If you trust the library, sure. But I've found that the same rules apply to
crypto libraries as to everything else: Obscure and complicated features are
far more likely to be buggy.

No crypto library is ever going to ship with a broken HMAC-SHA256 -- but I
can't say the same thing about AES-CCM.

~~~
tptacek
Seriously, Colin? You're talking about people that _don't_ know to use AES-256
instead of Blowfish, but _do_ know enough to homebrew instead of using a
library?

CCM and EAX aren't obscure. AE crypto has been in 3 of the last 4 designs I've
had to review. The fourth prompted a recent blog post of mine.

------
cperciva
This was largely inspired by Thomas's blog post yesterday about AES vs. RC4 --
he started me thinking "gee, someone really should sit down and tell people
what they should be using so that they don't keep doing dumb things like using
RC4".

------
sunir
Possibly truly stupid question, but what is the attack on md5ing passwords if
you also generate a random salt for each user? I could not find anything
online in the past ten minutes that suggests an attack, except for the md5
collision problem.

I don't understand the collision problem very well either. I know it's been
used to crack a certificate here or there, but it seems like it took a lot of
resources to crack one password.

~~~
tptacek
[http://www.matasano.com/log/958/enough-with-the-rainbow-
tabl...](http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-
you-need-to-know-about-secure-password-schemes/)

~~~
sunir
Thomas, thanks. That was immensely helpful. Now I have to figure out what I
want to do going forward. At least I already have per-user random salts.

------
artlogic
Can anyone explain:

"Client-server application security: Distribute the server's public RSA key
with the client code, and do not use SSL."

It seems like the point of this is to make sure that when communication moves
from the client, only the server with the proper private key can decrypt it -
BUT, aren't you just going to use OpenSSL to implement this (via TLS)? Is
there some other way to accomplish this I'm not aware of? What's he
specifically warning us against?

~~~
cperciva
I'm warning you against using a complex and error-prone protocol where you
don't need all the complexity. You might end up using OpenSSL anyway, but
using OpenSSL to perform an RSA encryption is vastly safer than using OpenSSL
to verify a certificate chain.

~~~
tptacek
I am a bit mystified by you warning people off SSL. It's complex because the
problem of establishing a trusted channel between two unrelated parties is
complex. Simpler protocols with the same constraints have failed.

You should be clearer with your recommendation. If you can relax the
constraint that the protocol has to work between strangers, then SSL offers
functionality you don't need, and the actual interface to SSL has moving parts
that might hurt you.

Most people who build crypto can't relax that constraint, even if they think
they can. We've beat several schemes that relied on pre-distributed public
keys because of the out-of-band channels that wound up getting grafted on to
bring new members into the group.

Finally, verifying a certificate chain _isn't_ hard. It's constructing a
verifiable certificate chain in the first place that has proven difficult. If
IE7 didn't offer the "bad certificate" click-through warning, and simply
failed the request, we'd be discussing the right problem instead of the red
herring.

~~~
cperciva
_You should be clearer with your recommendation. If you can relax the
constraint that the protocol has to work between strangers, then SSL offers
functionality you don't need, and the actual interface to SSL has moving parts
that might hurt you._

I specifically mentioned client-server applications, didn't I? If you are
handing out client code which talks to a server you run, you don't need the
protocol to work between strangers.

~~~
tptacek
Except for the part where you hand out the code and the certificate.

~~~
cperciva
You need a secure way of handing out client code, sure. There's no way to get
around that. But once you've figured out how to do that, you might as well
include the server public key.

If an attacker can mangle the server public key which you're distributing with
the client code, they can mangle the client code, at which point you've
already lost.

~~~
tptacek
So you draw an imaginary line around the parts of your application that have
simple security requirements, make recommendations about the stuff inside the
lines, ignore the stuff outside the lines, and berate the technologies that
deal with the stuff outside the lines.

Just so we're clear.

------
sweis
This is a good post, Colin.

One thing people reading it may not realize is the importance of picking good
IVs and the necessity of including them in the MAC.

Someone might just authenticate the ciphertext and neglect to include the IV,
leaving themselves open to a few attacks.

------
polos
The overall message is: I trust human intelligence -- and this is positive
(iff you're actually _using_ your intelligence).

In contrast, most crypto rants fall into the "laugh at them, as they're all
equally stupid" trap, which is not going to change humans into better...

~~~
tptacek
If you're trained and experienced, there is probably nothing about performing
standard appendectomy to challenge the intellect. But you're crazy if you
think that optimism about human intelligence is enough to allow an ordinary
smart person --- or maybe even an ER nurse --- to conduct one based on a
guidebook.

~~~
by
There are things to be learned from the article at more levels than just the
design of new protocols. For example, I would say this good advice that
applies to ordinary smart people:

"Do NOT store users' passwords. Do NOT hash them with MD5. Use a real key
derivation algorithm. PBKDF2 is the most official standard; but scrypt is
stronger. Please keep in mind that even if YOUR application isn't particularly
sensitive, your users are probably re-using passwords which they have used on
other, more sensitive, websites -- so if you screw up how you store your
users' passwords, you might end up doing them a lot of harm."

