[cryptography] [info] The NSA Is Building the Country’s Biggest Spy Center (Watch What You Say)

Marsh Ray marsh at extendedsubset.com
Thu Mar 22 00:44:59 EDT 2012

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 

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 

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

> (thinking about it more, my normal rule of "ignore the NSA always"
> should answer this :) )

No Such Adversary.

- Marsh

More information about the cryptography mailing list