Cryptographic Right Answers

http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html

by cperciva • 17 years ago

121 38 17 years ago

cperciva10• 17 years ago

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".

polos• 17 years ago

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...

tptacek15• 17 years ago

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• 17 years ago

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."

tptacek15• 17 years ago

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.

tptacek15• 17 years ago

Oh and another thing Colin, you jerk:

All of your recommendations die in embedded applications, where nobody will use HMAC-SHA256 (or SHA256 at all) or RSA.

;)

cperciva10• 17 years ago

This depends on how small your embedded systems are. If your system is too small to run RSA, it's probably too small to use any asymmetric crypto; and if it's too small to use HMAC-SHA256, it's probably too small to use any crypto at all.

There are certainly applications where I would revise my recommendations, but embedded isn't particularly one of them.

cperciva10• 17 years ago

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?"

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.

tptacek15• 17 years ago

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.

dfranke• 17 years ago

I'm with you on CTR mode: it's a uniquely dangerous recommendation to anyone who needs to be soliciting recommendations in the first place. If you're encrypting a file, then the obvious, elegant thing to do is to use position in the file as your counter. But then the moment you encrypt two files using the same key, you're screwed: you've just committed the equivalent of reusing a one-time pad. I feel like ever mentioning CTR mode to a novice without bringing this up is like inviting a guest into your house and forgetting to mention that you've rigged the door handle to explode if you turn it in the wrong direction.

tptacek15• 17 years ago

I'm actually not anti-CTR mode; my recommendation (use EAX mode) has basically the same problem --- EAX is just CTR + OMAC.

You're right that stream ciphers blow up more spectacularly than block encryption does. You have to be sure not to re-use anything (counters, nonces, keys, etc). If "don't overfill a buffer" is an easy prescription that cost industry $4+bn USD, it's hard to imagine how unlikely it is people can avoid screwing up "don't reuse anything".

On the other hand, differentiatable errors cause spectacular problems with block encryption. See: the "bad padding" error message that decrypts entire AES blocks a byte at a time.

artlogic2• 17 years ago

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?

cperciva10• 17 years ago

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.

CrLf• 17 years ago

Implementing your own protocol is far worse than taking SSL and all its "complexity", which is there for a reason.

In fact, never implement your own cryptographic protocol unless you _really_ have to. And even then, think twice.

cscott• 17 years ago

I'm concerned about the lack of revocation that comes with bundling a key in source. Shouldn't you warn people in your note that if the key is compromised, you're going to have a difficult time?

rcoder• 17 years ago

This is all the more critical when you consider how the usual web developer handles the complexities of chained certificate verification: namely, by disabling verification entirely, and instead trusting every upstream certificate as offered.

For example, as of Rails 2.3, ActiveResource (the default RESTful web service API client used in many Rails applications) disables all SSL verification whenever SSL is used, without so much as a configuration flag to enable it again.

tptacek15• 17 years ago

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.

artlogic2• 17 years ago

Ah - I see, essentially:

"Don't use a signed server certificates, etc... when you don't have to, instead use a RSA public key."

It was the OpenSSL thing that confused me. I forget that TLS is way more than RSA over TCP sometimes. Thanks for the clarification.

sunir2• 17 years ago

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.

tptacek15• 17 years ago

http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...

sunir2• 17 years ago

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.

jameskpolk• 17 years ago

The collision problem is a huge deal. You can no longer trust a MD5 signed object.

http://www.mscs.dal.ca/~selinger/md5collision/ has some great, and very scary examples.

sweis• 17 years ago

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.

Cryptographic Right Answers

Related Stories