AES-GCM and AEAD Protected Data Packet (IETF draft)

[Tankred Hase]

> They now have a strange mail archive but here is my last message
> regrading this topic (also copied below):
> 
> <https://mailarchive.ietf.org/arch/msg/openpgp/gAPnZgCtjXNpHvl_hiXogcBrtsg>

Thanks!

> BTW, there will be a WG session at IETF-95 on April 6, 11:00 - 12:30.
> You may participate remotely:
> 
> <http://www.ietf.org/meeting/95/remote-participation.html>

Sounds interesting. I might as well join in.

>> I have no objections against supporting multiple authenticated modes,
>> including OCB. Like I said, the reason I would advocate for GCM is
> 
> That is not going to work.  I am pretty sure that there is already a
> rough concensus in the WG that we will add only one new encryption
> format which will eventually replace the MDC format.  The current
> discussion is around the idea to detecta corrupt large message early and
> not only after the full message has been processed.

Understood. That makes sense.

> GCM has only be developed to avoid the OCB patent which in fact is
> irrelevant these days.  And frankly it will take at least 5 years before
> a new AE mode in OpenPGP will be widely deployed - by then the patent
> has expired.
> 
> OCB is way easier than GCM and thus also easier to implement in JS

My main concern is not the developer experience, but rather the user experience:

# Security

Crypto primitives written in JS are widely considered to be insecure due to timing attack vectors. This is why the WebCrypto api was introduced in the first place. Browsers all ship with TLS stacks like NSS and OpenSSL/BoringSSL that already include primitives like AES-GCM. These are well tested and subject to release process with timely security updates. This means that web developers should not be rolling their own crypto and always use the WebCrypto api provided by browsers.

# Performance

I have done some benchmarks using Chrome's GCM implementation and it's about 30x faster than an optimized JS implementation on my Corei5:

https://github.com/openpgpjs/openpgpjs/pull/430#issuecomment-200469142

# Platform support

There are good reasons why OFB has not been standardized for TLS. As Matthew Green points out in his post, probably due to patent issues. Even if the patent issues are gone in 5 years, GCM will still have better support in browsers and other runtimes/libraries due to its head start. In 5 years we probably won't care about OFB anyway since we'll all be using a modern primitive like DJB's ChaCha20-Poly1305 (which is already being used in Chrome on mobile devices that don't have hardware acceleration for GCM).

JavaScript in contrast to programming in a native environment like C/C++ simply has certain constraints, which makes us more dependent on the rest of the ecosystem. I understand that GnuPG does not have these constraints. But given that OpenPGP strives to be an interoperable open standard focused on growing its user base, these factors should be considered when choosing a new authenticated mode.

Tankred