AES-GCM and AEAD Protected Data Packet (IETF draft)
mail at tankredhase.de
Thu Mar 24 11:41:14 CET 2016
> They now have a strange mail archive but here is my last message
> regrading this topic (also copied below):
> BTW, there will be a WG session at IETF-95 on April 6, 11:00 - 12:30.
> You may participate remotely:
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:
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.
I have done some benchmarks using Chrome's GCM implementation and it's about 30x faster than an optimized JS implementation on my Corei5:
# 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).
More information about the Gnupg-users