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

[Aaron Zauner]

* Gunnar Haslinger <gh.bettercrypto at hitco.at> [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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20151103/eac5d842/attachment.sig>