* Gunnar Haslinger <[email protected]> [02/11/2015 21:25:03] wrote: > 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
I think I can shed some light on that matter. When we started out with bettercrypto in the fall of 2013 concerns about NIST curves recently sprung up all over the internet, with (some) ECC cryptographers being particularly worried. We now know [0] that these curves have likely never been backdoored. Exploiting these potential backdoors is extremely difficult and further worries about implementations that might have been wrong because of difficult-to-implement choices with some of the NIST curves have since been checked by a lot of people (at least for OpenSSL etc.). The performance overhead of classic diffie-hellman is non-negligible; back then I voiced some concerns about that. For example: CAMELLIA is barely supported by common user-agents anymore and the TLS 1.3 spec is going to entirely abandon it (and almost all cipher primitives currently specified for use in TLS 1.2 - there're just too many). What we'll get are a couple of verified ciphers, key-exchange methods (see OPTLS [1]) that should suffice for further use. Post-quantum algorithms are nowhere near the scrutiny needed for cryptographers to be sure that they're safe, and quite a lot changes with these algorithms over them timespan of only a year [2]. >=20 > > The reasoning for camellia is AFAIR that it can be used as sane > > fallback if a flaw in AES is found.=20 >=20 > 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. See above. Added to that is a poor performance track record of CAMELLIA vs. hardware-accelerated AEAD modes (GCM in particular) on modern instruction set architectures. We're down to GCM and ChaCha20/Poly1305 for TLS 1.3, but I hope to push AES-OCB (very elegant mode that provides provable-secure high-speed performance in software without need for plattform specific instructions). Historically OCB had been considered a lot of times but not used because of patents. Rogaway, Jutla (IBM) and myself have been working on that since last january and we now have patent exemptions for AES-OCB mode in TLS. The draft and related IPR declarations can be found here: Internet Draft: https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ IPR: https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-zauner-t= ls-aes-ocb There's some interest in the TLS working group and, very recently, the newly-restarted OpenPGP working group. Let's see,.. We're still missing TLS related code-parts in OpenSSL for implementers to use right-away. >=20 > > "performance: aes-128 should be preferred over aes-256. aes-256 has no > > relevant security over the 128 variant" >=20 > Thx. for your Performance Measurement >=20 > $ openssl speed -evp aes-128-cbc aes-192-cbc aes-256-cbc >=20 > Did the same here, one OpenVZ virtualized System, one Azure-Cloud (Window= s Server 2012 HyperV) virtualized System. >=20 > Compared it to your results, quite the same, mostly AES128 ist ~40% faste= r 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. AES256 provides better security than AES128 (all attacks I've seen are purely academic, reduced round etc.). Nevertheless I feel the same way, AES128 should be preferred; and that exactly what we're doing with the latest version of our bettercrypto cipherstring recommendation: https://git.bettercrypto.org/ach-master.git/blob/HEAD:/src/common/cipherStr= ingB.tex Mind you: GCM performs poorly on embedded devices or most mobile plattforms, there're also some concerns about sidechannel/timing attacks. HTH, Aaron [0] - https://eprint.iacr.org/2015/1018 [1] - https://eprint.iacr.org/2015/978 [2] - http://pqc.space/doc/talkproposal-30oct15.pdf (via Hanno Boeck)
signature.asc
Description: Digital signature
_______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
