-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mar 3, 2013, at 7:05 PM, Patrick Pelletier <[email protected]> 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.)
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.2.0 (Build 1672)
Charset: iso-8859-1
wj8DBQFRNFG4sTedWZOD3gYRAi3IAKDpx3yppkrX/E+wgOyGT8Pv2GjqogCff+YH
ixIc+D0VqEB/NVMmhPV/p2k=
=DawS
-----END PGP SIGNATURE-----
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
