[cryptography] Workshop on Real-World Cryptography
jon at callas.org
Mon Mar 4 02:48:07 EST 2013
-----BEGIN PGP SIGNED MESSAGE-----
On Mar 3, 2013, at 7:05 PM, Patrick Pelletier <code at funwithsoftware.org> wrote:
> This article surprised me, because it could almost be read as an argument against AES (or even against block ciphers in general). Which seems to contradict the common cryptographic wisdom of "just use AES and be done with it."
> Besides the argument about AES having timing side-channels in #9, the room 101 section at the end suggests we should do away with not only CBC, but also AES-GCM, which is commonly touted as the solution to CBC's woes. (He admits it was his most controversial point, and I'm curious how it was received when the talk was given.) But I believe that if we rule out both CBC and AES-GCM ciphersuites in TLS, that leaves us with only RC4. (And indeed, unsurprisingly given the author, RC4 seems to be what Google's sites prefer.)
Sadly, it's more complex than that. There are a bunch of rules of thumb that are independent of any particular cipher. Here's a few:
* Stream ciphers are typically a seeded PRNG that XORs the pseudo-random stream (colloquially called a keystream, but I think would be better called an r-stream) onto the plaintext. Everything from Lorentz to GCM works this way. This means that known plaintext means known keystream. That means that if you reuse the keystream, then there's a cipher break and it's independent of the cipher construction or key size. So they are very bad to use on jobs like encrypting disk blocks.
* Block ciphers need chaining modes to be effective, otherwise you can get a codebook built up. This is why ECB is suboptimal. Every chaining mode has its own plusses and minuses. CBC has weaknesses when you use it in a data stream, as opposed to a data block. The recent SSL attacks are attacks on the chaining mode more than on the cipher. Don't use CBC for a data stream. Counter mode turns a block cipher into a stream cipher and makes it good for streams, but then it gets all the drawbacks of stream ciphers. If you forget that counter mode is no longer a block cipher but a stream cipher, you can hurt yourself. But similarly, we've learned that CBC is tetchy when used in a data stream.
CFB mode is kinda part stream cipher and part block cipher. It's CBC mode's poor relation for no good reason. There many cases where a CBC weakness (particularly one that boils down to a padding attack) could be fixed by using CFB mode. People don't though, for no good reason. There are plenty of places to use it -- but also look at the Katz-Schneier attack against OpenPGP, that was essentially an attack on CFB mode. Ironically, the easiest way to mitigate that attack is to compress your data before encrypting.
* Every cipher and system is going to have weak points. There are ones worth worrying about and ones not worth worrying about. There are even ones worth arguing over or even deciding that gentlepersons can disagree. There's a very old saying, "there ain't a lock that can't be picked" and it's true of crypto, too.
If you start hyperventilating about too many things, you *will* just throw your hands up in the air. Side channels are important. Pay attention to them. But if you start thinking too hard and expect perfect security, you won't do anything, and plaintext is always worse than ciphertext. That sounds obvious, but you would be surprised how hard it is for people to internalize that.
You can use PKCS#1 properly, if you know what you're doing. You can screw up GCM if you don't. (Personally, I don't like GCM. I think it's too tetchy. But I'm pretty blasé about PKCS#1, because I'm used to pouring over it to make sure it's done right.)
* There are many crypto problems that good engineering can paper over. There are many that don't really show up in the real world. There are others that manifest themselves for whatever reason. Engineering is hard. Don't panic.
* There is a common thing that people do that I call "engineering from ignorance" as opposed to "engineering from knowledge." For example, if you jump from AES or RC4 because of what you know about it to a cipher that hasn't been analyzed, you are engineering from ignorance. You're jumping from the devil you know to the devil you don't know. People like to do that, especially ones who want to live in a perfect world where ciphers have no drawbacks and there's no friction.
> It seems like we've been told for ages that RC4 is old and busted, and that AES is the one-size-fits-all algorithm, and yet recent developments like BEAST and Lucky 13 seem to be pushing us back into the arms of RC4 and away from AES.
What do you mean "we"?
RC4 got a bad rep because it has some weaknesses and because a lot of people didn't realize that you never send a stream cipher to do a block cipher's job. It has some other issues, like that its construction makes it hard to accelerate. For a cipher of its age, it's not bad, really, assuming you know how to use it. The hype against it has been overblown, too.
But BEAST is a banana attack. Lucky 13 is brilliant, but one of those things that can be solved in engineering. As effin brilliant as it is, it's very hard to make work in the real world, which means it's easy to fix by engineering.
> Although cipher suite proliferation is a common criticism of TLS (and indeed, it seems like neither Camellia nor SEED nor ARIA offer any benefit over AES as far as I'm aware, though I'm not a cryptographer), I wonder if there's benefit in adding a ciphersuite for a new stream cipher (such as Salsa20) to TLS, to eventually replace RC4? Such a proposal could at least have clearly-stated goals (faster than RC4 and AES, more secure than RC4, avoiding the side-channel issues and CBC issues of AES), versus the unclear and never-stated goals of yet-another-128-bit-block-cipher.
A common tension is that options are bad, but options are also good.
Another tension is engineering from knowledge or ignorance. It always feels good to move away from something that has known problems to something that doesn't, but that new thing will get its own problems in another decade. And then what?
Of course, there are plenty of reasons to continue with cryptographic development. We don't want to just roll up shop, and consequently a lot of brouhaha you hear is as much people wanting to justify new toys as it is anything else. I'm not saying that's bad. I'm not saying I don't do it, too. I'm just saying it happens. (Ask me what I want to do with very-wide tweakable block ciphers, and how they could fix the problems you mention.)
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.2.0 (Build 1672)
-----END PGP SIGNATURE-----
More information about the cryptography