[cryptography] Repeated Encryptions Considered.... ?
decoy at iki.fi
Sun Jun 19 18:12:19 EDT 2011
On 2011-06-19, Jack Lloyd wrote:
> There is one case I have seen where encryption with independent
> ciphers does make sense - for certification reasons. Currently
> Tahoe-LAFS uses AES to encrypt content, however there is a plan to
> encrypt all messages first with XSalsa20, then AES, so that side
> channel attacks on AES are no longer relevant [...]
Do you happen to have a link for the underlying rationale? "No longer
relevant" sounds a bit strong to me, especially with a cipher as well
studied as AES is. I mean, wouldn't it be easier to just implement it
better, and/or to add to the certification requirements?
Now that you gave me the opportunity, I do have to add one point about
cascaded cipher strength which I forgot to mention. Namely, one of the
simplest, most common, oldest, and also most fatal mistakes here is that
symmetric ciphers *can* leak information about the key. Thus, if you
happen to place a leaky cipher last, it might enable somebody to figure
out the key, in *particular* if the earlier cipher is strong, so that
pseudorandomness assumptions apply, statistically speaking. Often you'd
be using the same key, or the same source data for the key derivation
function, all over your cascade, which could jeopardize even the
strongest one in the chain if the last one leaked.
That's an architectural mistake of course, but a common one, and
something that's rather difficult to avoid e.g. if your key has low
entropy to begin with. KDFs and especially optimized key schedules are
rather intricate, after all.
How would you then know which cipher was the strongest, so to be placed
the last, if you don't know enough to just pick the strongest cipher and
be done with it without compounding? If you think about the
probabilities, this possibility not only expectedly undermines the
cascade. But there's also an argument to be made that those who fudged
the issue by encrypting multiple times have already signaled that they
aren't the ones who should be designing the crypto architecture in the
This is of course from the book, but I still thought a reminder might
help the original poster with his question.
Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
More information about the cryptography