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

[Aaron Zauner]

Hi,

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

I would not totally agree there. This comes back to my point that
there's far less academic research on CAMELLIA than on AES - for
non-public research: we just don't know.

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

How exactly is CAMELLIA helping here? Such a key leak probably affects
multiple ciphers.

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

There's still no security proof for AES to the best of my knowledge,
some block-cipher modes come with proofs attached though.

> 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).
>

BEAST was in 2011. What we saw this year is IETF prohibiting use of RC4.
Same thing for SSLv3.


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

Not sure where using exotic ciphers helps here, these are code-branches
people look at far less. For example: BoringSSL removed all CAMELLIA
code (i.e. chromium, android etc. won't support it anymore, since
they've switched their entire codebade to BoringSSL a few weeks back).

Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20151109/3bdcc4d6/attachment.sig>