[Ach] EDH/ECDH, AES128/AES256 - was: Secure E-Mail Transport based on DNSSec/TLSA/DANE

[Terje Elde]

> On 03 Nov 2015, at 22:59, Gunnar Haslinger <gh.bettercrypto at hitco.at> wrote:
> 
> Am 03.11.2015 um 21:41 schrieb Terje Elde:
> 
>> ... Camellia ....
>> For systems I might not be responsible for in 5 years, I'd rather leave it in.
> 
> Could be a good decision or not, depending on how things come.
> Maybe Camellia turns out to be broken earlier than AES. Then you have to
> touch the systems you are not responsible for. So it's a 50:50 chance if
> AES or Camellia gets broken earlier. If I have two ciphersuites enabled
> the chance of having to change the configuration is doubled.

I do get your point, but I mostly disagree with it.  There seems to be general agreement of there being a pretty low risk of either AES or Camellia getting broken significantly in the next 5.  If you do a standard analysis of risk (low) * work (low), you pretty much come out with the risk of having to change cipher being not high.

Also, I think it wouldn’t matter much, and here’s why:

All SSL-versjons since SSL2 (meaning anything that should actually be used) all have cipher-downgrade protection.  If you support AES and Camellia, prefer AES, and the client supports AES, you’ll use AES.  Even if you support Camellia.  In such a case, it doesn’t really hurt you if Camellia is broken, you won’t use it.  Sure, if it were *completely* broken, I’d recommend removing it from the config, but that’s unlikely.

Take DES for example.  Obviously nobody in their right mind would recommend you use DES these days, but have a look at the attack-menu, best attacks:

 - Differential cryptanalysis - 2^49 chosen plaintexts.
 - Linear Cryptanalysis - 2^39 known plaintexts.
 - Improved Davies’ attack: 2^59 known plaintexts, 51% success rate

That is, even the best attack would require 64GB of known plaintext, and what you’d gain at the end of that, would be recovering the key to your own session.

The biggest failure of DES for typical web traffic, then becomes the key or strength itself.  At 2^56, that’s obviously a problem, but it’s still interesting to note that with all it’s breakage, this old beast from 1975 would still offer most of it’s “bit-strength” for typical web traffic and similar.  My point isn’t that it’d be okay to use DES - obviously it wouldn’t - the point is that for typical web traffic, the real-world security of DES now, isn’t all that different from what it was when it was introduced.  The “bit strength” is about the same for practical attacks, it’s just that the “bit-strength” isn’t good enough anymore.

Okay, so I’m oversimplifying, and new classes of attacks could be found etc, but bottom line is that it’s highly unlikely that security for either AES or Camellia would go from “perfectly secure” to “just like plaintext” overnight.

So let’s look at how an attack would be likely to play out;
Say there’s a weakness in Camellia, and it turns out being as broken as DES.  That  could mean you’d find a linear cryptanalysis attack that’s reduce the security of 128-bits Camellia to 2^110 known plaintexts.  From a crypographic perspective, that’d be a crisis.  From a practical perspective, it wouldn’t matter, and there’s be no rush to instantly drop it from your config, especially if you know you won’t use it anyway, you’ll use AES.

Focusing on practical attacks, there’s a lot bigger chance that there’ll be issues with things like key leakage from AESNI, errors in cryptographic implementations, and so on.  If there were to be an attack that lead to key-leakage on all windows-installs for example, and you have both ciphers supported, any session would still be secure if *either* server or browser drops support for AES.

If browsers drop AES, your alternatives are pretty much limited to:
 - Camellia
 - Plain HTTP
 - Site unavailable

I know which one of those I’d prefer.


Or to try to sum it up, if you support both (Camellia only at end of list), then:

If neither cipher nor implementations has a problem, you’re fine.
If AES has a problem, you’ll fall back to Camellia if either server or client disables AES.
If Camellia has a problem, you’re fine, because you’ll use AES.
If both has a problem, you’re still better off, because either your or browsers can steer things towards the “least broken”.

While a complete break of AES is unlikely, it doesn’t hurt to retain options, esp. if you also consider risk of non-cryptographic attacks, such as key-leakage due to implementation-errors, or other similar issues.

To me, this seems like an obviously Good Thing.  Am I missing something?

> Turn back time 2 years.
> You probably would have enabled AES and RC4.

Please try to avoid the “you had a ham sandwich yesterday, so you probably eat ham sandwiches every day”-type of arguments.  At best it comes off as missing the logical misstep, and it can easily come across as simply offensive (I get that that probably wasn’t intended).

Other than that, Aaron Zauner pretty much covered it.

> As nobody can predict future the chance to do it wrong is equal regardless how you decide.

I suppose about half my point is that that’s not the case.

With both, you’re no worse off than with AES-only.  With only AES, you’ve tossed away an option to mitigate issues, and not gained anything significant by doing it.

(okay, so that’s slightly simplified.  If you can both find a significant flaw in Camellia, and also a way to circumvent cipher downgrade protection, that could be an issue.  Compared to the risk of a major issue in either AES or - more likely - an implementation, that’s a significantly lower risk though),

Terje Elde