[Ach] Cipher-Order: AES128/AES256 - was: Secure E-Mail Transport based on DNSSec/TLSA/DANE

[Terje Elde]

> On 09 Nov 2015, at 12:56, Aaron Zauner <azet at azet.org> wrote:
> 
> There's only one chinese team working on CAMELLIA attacks as far as I
> can tell, vs. a lot of people that work on AES attacks. As people have
> mentioned before: a attack that will break AES will likely also break
> CAMELLIA.

Reverse is also mostly (but not certainly); If AES is secure, there’s a good chance that Camellia is as well.

The one thing that worries me with the discussion of removing Camellia, is that arguments for are almost always focused exclusively on a cryptographic/mathematic perspective.  The arguments are often true, valid and good, but they’re also narrow in scope.  I’m not worried about AES from a crypto/math-perspective, what worries me is that those arguing for Camellia-removal seem to ignore the practical aspect.  It’s *far* more likely that there’ll be an engineering-break, than a math-break.  What happens if someone finds a key-leakage issue with a hardware crypto-implementation, allowing leaking keys between XEN-instances for example?

There seems to be an implied “the math is solid, therefor AES the algoritm is secure, therefore all uses of AES is secure”.  The first conclusion is solid, but not the second.

I find the timing of this a bit puzzling to be honest.  It’s only this very year that we saw usage of RC4 to mitigate BEAST for example.  That is, the math-solid algoritms got shifted out by some, in favour of math-broken, because they figured the tradeoff was better.  (Lots could be said about if that was a good call or not).

It tends not to be the crypto math that gets broken, but usage, implementations, etc.

Terje