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

[Gunnar Haslinger]

Sebastian analyzed my used CipherString for Apache in my Paper, and it's
not the originally Bettercrypto-Cipherstring.

we are talking about this (comparison):
https://it-sec.ovh/doc/myCipherstring-versus-BetterCrypto.png


Am 02.11.2015 um 17:59 schrieb Sebastian:
> en: "the faster ECDHE variants should be preferred over the slower EDH
> variants"
>
> I would like to discuss this here for ach too.
> I think the current recommendation is basically 2 years old and the
> crypto landscape has changed. 

I don't know what lead to preferring EDH against ECDH in detail - maybe
some "Risk" that ECDH is not so well known / researched compared to EDH?
As nowadays DH with only 1024bit is not suitable any more and DH with
2048bit is a bit slow this lead to my decision to prefer ECDH over EDH

> The reasoning for camellia is AFAIR that it can be used as sane
> fallback if a flaw in AES is found. 

OK, point taken.
but i could easily enable it when such a Situation happens, and
hopefully AES doesn't get broken the next 15+ years, could lead into a
disaster.

> "performance: aes-128 should be preferred over aes-256. aes-256 has no
> relevant security over the 128 variant"

Thx. for your Performance Measurement

$ openssl speed -evp aes-128-cbc aes-192-cbc aes-256-cbc

Did the same here, one OpenVZ virtualized System, one Azure-Cloud (Windows Server 2012 HyperV) virtualized System.

Compared it to your results, quite the same, mostly AES128 ist ~40% faster then AES256 (30-55% depending on Blocksize and Machine).
For me AES256 currently has no practically stronger security than AES128, so I decided to prefer AES128 in the Cipher Suites to AES256. If a client likes to connect using AES256 this would be fine, but straight forward all Clients would connect using AES128.


regards,
Gunnar