Support AEAD cipher modes

[kruton]

Add support for AEAD (Authenticated Encryption with Additional Data) that obviate the need for a separate MAC step. Modes such as AES-GCM, AES-CCM, and AES-XTS are examples. Combining the encryption and authentication steps leads to a speed-up since the library can use optimizations since it is doing both operations concurrently.

[kruton]

Adds AEAD cipher modes for OpenSSL

[kruton]

My main motivation was that this is a recommended mode according to NIST Special Publication 800-38D, but I was asked for benchmark numbers because of my original wording of the ticket. Newer Intel processors with the AES-NI instructions have specific acceleration for this mode which makes AES-256-GCM twice as fast as AES-256-CBC-HMAC-SHA1 fused for large packets. Note that OpenVPN doesn't use the accelerated fused version because it currently calculates the HMAC value first, so the actual performance of OpenVPN for AES-256-CBC + HMAC-SHA1 will be worse than this.

Here are "openssl speed" numbers from a E3-1265L @ 2.50GHz ("openssl speed -elapsed -evp ..."):

The 'numbers' are in 1000s of bytes per second processed.

type	16 bytes	64 bytes	256 bytes	1024 bytes	8192 bytes
aes-256-gcm	251664.07k	660190.72k	871622.06k	933753.86k	955528.53k
aes-256-cbc-hmac-sha1	200006.11k	245678.55k	359765.76k	414973.95k	432472.06k

[kruton]

It doesn't appear PolarSSL has fully integrated GCM mode into its main cipher API (​https://polarssl.org/api/cipher_8h_source.html). I'd rather wait until they have that API finished before attempting PolarSSL support.

[Samuli Seppänen]

This issue has been discussed in detail in ​this email thread.

[IncreasedSecurity]

I would note that aside from NIST SP 800-38D, another reason to add them is the European Union Agency for Network and Information Security 2013 Algorithms, Key Sizes and Parameters Report, published October 2013, which endorses GCM.

[kruton]

The latest PolarSSL supports GCM mode in their cipher API now.

[Steffan Karger]

Just a quick heads-up: AES-GCM is on my wishlist for 2.4 and I have a proof-of-concept patch that works for both OpenSSL and PolarSSL builds. There are some rough edges I'd like to polish up first, but once that's done I'll post a patch (set) to the mailing list.

[Steffan Karger]

No final version yet, but a functional preview is available at:
​https://github.com/syzzer/openvpn/tree/aead-cipher-modes5

This implementation introduces a new data channel packet format for CTR-based crypto modes (e.g. GCM and CCM), which uses the TLS session id as an implicit part of the IV to reduce packet size.

Comments are welcome.

[dkg]

It would be great if this could be accelerated. It's clear from the discussion on ​the applied crypto hardening list that the lack of AEAD support is a problem for that project's endorsement of OpenVPN.

[Steffan Karger]

Thanks for the pointer. I agree we should finally finish this. A more recent version of the code can be found here:
​https://github.com/syzzer/openvpn/tree/aead-cipher-modes8
Comments and testers are very welcome!

I do however *not* agree that the lack of AEAD in the data channel should be a problem for endorsing OpenVPN. I wrote a reply to the pull request that triggered the list discussion, since I was not on the ACH list before:
​https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91#issuecomment-75365286

[Gert Döring]

"must have!" for 2.4 alpha

[kruton]

Did this end up making it in?

[Steffan Karger]

Not yet, but I just pushed a new branch to github that I intend to send to the list Real Soon Now:
​https://github.com/syzzer/openvpn/tree/aead-cipher-modes13

[Steffan Karger]

And thanks to fast review by plaisthos, everything is in master now!

Most relevant commit: 66407e11c4746e564bd4285e9c1a1805ecfd82bd.