Opened 9 years ago

Closed 6 years ago

#301 closed Patch submission (fixed)

Support AEAD cipher modes

Reported by: kruton Owned by: Steffan Karger
Priority: major Milestone: alpha 2.4
Component: Crypto Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: AEAD GCM CCM XTS


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.

Attachments (1)

0001-Add-AEAD-cipher-modes.patch (14.7 KB) - added by kruton 9 years ago.
Adds AEAD cipher modes for OpenSSL

Download all attachments as: .zip

Change History (15)

Changed 9 years ago by kruton

Adds AEAD cipher modes for OpenSSL

comment:1 Changed 9 years ago by 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

comment:2 Changed 9 years ago by kruton

It doesn't appear PolarSSL has fully integrated GCM mode into its main cipher API ( I'd rather wait until they have that API finished before attempting PolarSSL support.

comment:3 Changed 9 years ago by Samuli Seppänen

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

comment:4 Changed 9 years ago by Samuli Seppänen

Owner: set to Steffan Karger
Status: newassigned

comment:5 Changed 8 years ago by 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 states:

"This means at the time of writing we would only recommend the following cipher suites, for
future use within TLS

  • _WITH_Camellia\index{Camellia}_128_GCM_SHA256,
  • _WITH_AES_128_GCM_SHA256,
  • _WITH_Camellia\index{Camellia}_256_GCM_SHA384,
  • _WITH_AES_256_GCM_SHA384,
  • _WITH_AES_128_CCM,
  • _WITH_AES_128_CCM_8,
  • _WITH_AES_256_CCM,
  • _WITH_AES_256_CCM_8.

where is suffix denoting the underlying key exchange primitive."
(\index{Camellia} typos from original document).

Version 0, edited 8 years ago by IncreasedSecurity (next)

comment:6 Changed 8 years ago by kruton

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

comment:7 Changed 8 years ago by Steffan Karger

Milestone: release 2.4
Status: assignedaccepted

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.

comment:8 Changed 8 years ago by Steffan Karger

No final version yet, but a functional preview is available at:

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.

comment:9 Changed 7 years ago by 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.

comment:10 Changed 7 years ago by Steffan Karger

Thanks for the pointer. I agree we should finally finish this. A more recent version of the code can be found here:
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:

comment:11 Changed 7 years ago by Gert Döring

Milestone: release 2.4alpha 2.4

"must have!" for 2.4 alpha

comment:12 Changed 7 years ago by kruton

Did this end up making it in?

comment:13 Changed 7 years ago by Steffan Karger

Not yet, but I just pushed a new branch to github that I intend to send to the list Real Soon Now:

comment:14 Changed 6 years ago by Steffan Karger

Resolution: fixed
Status: acceptedclosed

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

Most relevant commit: 66407e11c4746e564bd4285e9c1a1805ecfd82bd.

Note: See TracTickets for help on using tickets.