On 03/21/2012 08:54 PM, ianG wrote:
Or, is the advantage that CBC and other modes have - obfuscation of the
ciphertext with variation stolen from the plaintext - of such low value
in the scheme of things that these things make no difference?
Just thinking out loud here.
CBC certainly seems like a big improvement over ECB.
It used to be that we were supposed to be concerned about known and
related plaintext weakening the cipher. Apps randomized certain fields
and did compression on the plaintext. Eventually AES was specified
explicitly to be safe against related plaintext/ciphertext/key attacks.
Today we live in a world where both the plaintext and the network are
downright malicious as a matter of course. Compression proves to be
buggy and hackers have turned exploitation of crash bugs into fine art.
IMHO, today at the network level we ought to be most concerned about
implementation complexity and adaptive plaintext, padding, timing, and
traffic attacks.
The large percentage of pwned endpoints is another discussion altogether.
Is the
choice of mode irrelevant if AES has a weakness?
Probably depends on the weakness?
An advantage of CTR is that even an adversary with that adaptive
chosen-plaintext capability can't feed data into the block cipher. A
disadvantage of CTR is that only a counter and a RNG-produced nonce feed
into the block cipher, but at least the implementor is in position to
secure that properly. So not only is it known plaintext going into the
block cipher, it is very highly related plaintext.
CBC doesn't turn known plaintext into unknown plaintext, it just whitens
it and un-relates it. In the process, it also ensures the attacker has a
statistically diverse set of known PT-CT pairs in his sample. Maybe that
makes things easier for him somehow?
But even in CTR mode, the internal values are going to look similarly
random after enough rounds for a full diffusion to have taken place
(although it now depends on the key and is no longer fully known to the
attacker).
So if you were concerned about related plaintext attacks with CTR mode,
perhaps you would feel more comfortable with a few additional rounds in
your block cipher? AES-256 for example. (I'm tempted to suggest
double-AES with the same key but I think some folks might get mad at me :-)
Your protocol might do this already, but you could have a separate
random nonce feeding into the KDF. For example, TLS is really good about
never using the same symmetric key twice, even between the same
endpoints, as long as at least one of them has a working RNG. This
doesn't directly addresses the related-ness of CTR plaintexts, but maybe
it reduces the risk of accidentally reusing a CTR nonce/IV with the same
key.
(context here is that I am examining an older protocol of mine with
thought of replacing it, and wonder which mode to prefer...)
CBC mode seems to be a lot trickier to get right in practice. We've seen
various ways that subtle things like predictable IVs or imperfect
padding validation can make it exploitable in real applications.
It's almost as if CBC mode is some kind of high-orbit electron that,
given the slightest provocation, spontaneously decays to its ground
state of ECB mode (and emits a photon carrying away the security in the
process).
(thinking about it more, my normal rule of "ignore the NSA always"
should answer this :) )
No Such Adversary.
- Marsh
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
