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

[Alexander Wuerstlein]

On 2015-11-09T13:06, Terje Elde <terje at elde.net> wrote:
> 
> > 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.

Also, "the math" being non-solid might not stem from a problem that is
shared between AES and Camellia but from their differences. E.g. magic
constants used in both Ciphers might differ sufficiently in certain
aspects to make one vulnerable, while the other remains solid. For a
historical example of what I mean, see the NSA's choice of s-boxes for
DES.

Disclaimer: I'm not a mathematician and certainly not knowledgable
enough to make any determination on the matter. But from the extremely
long time it takes to establish Ciphers, Hashes or other cryptographic
building blocks out there, I think one needs to pre-establish at least
one alternative for everything so an alternative is available, should
things go south. Camellia might not be the ideal AES alternative, but
its the only one with any current support in protocols. As soon as there
is another Cipher that can be used, Camellia could be phased out for
being to similar to AES, but not before.

For an example of how things might break, just imagine a situation were
SHA-1 hadn't been introduced as an MD5-replacement, or SHA-2 as a
replacement for SHA-1. Its still all happening very slowly, but at least
the alternative is available. 




Ciao,

Alexander Wuerstlein.