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 _______________________________________________ Ach mailing list [email protected] http://lists.cert.at/cgi-bin/mailman/listinfo/ach
