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 first place.
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 - [email protected], http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
