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

[Tankred Hase]

> Am 25.03.2016 um 03:20 schrieb Werner Koch <wk at gnupg.org>:
> 
> On Thu, 24 Mar 2016 11:41, mail at tankredhase.de said:
> 
>> Crypto primitives written in JS are widely considered to be insecure
>> due to timing attack vectors. This is why the WebCrypto api was
> 
> and due to lot of other reasons.  But this is not a JavaScript specific
> thing but matter of fact for all software implementations.

I'm aware with all the other arguments. Most are not problems of JavaScript. Together with constant time implementations of crypto primitives provided by native apis, programming the rest of the OpenPGP code in a memory safe language has many advantages. The problems are the way some applications choose to package their crypto. Using signed/installed applications and runtimes that enforce a strict Content Security Policy like browser extensions, Chrome Apps (see WhisperSystem's Signal-Desktop app) or Electron, developers can mitigate the web's attack vectors.

Whether we like it or not the fact remains that most users today use webmail. Browser extensions like Mailvelope allow us to go to where the user is.

But you're right this is not a JavaScript only discussion and I don't want to start a JS vs. native discussion.

>> NSS and OpenSSL/BoringSSL that already include primitives like
>> AES-GCM. These are well tested and subject to release process with
> 
> You may want to read
> 
>  <http://www.metzdowd.com/pipermail/cryptography/2016-March/028824.html>
>  From: Peter Gutmann <pgut001 at cs.auckland.ac.nz>
> 
>  On the Impending Crypto Monoculture
>  ===================================
> 
>  A number of IETF standards groups are currently in the process of
>  applying the second-system effect to redesigning their crypto
>  protocols.  A major feature of these changes includes the dropping of
>  traditional encryption algorithms and mechanisms like RSA, DH,
>  ECDH/ECDSA, SHA-2, and AES, for a completely different set of
>  mechanisms, including Curve25519 (designed by Dan Bernstein et al),
>  EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and
>  ChaCha20 (by, you guessed it, Bernstein).
> 
>  What's more, the reference implementations of these algorithms also
>  come from Dan Bernstein (again with help from others), leading to a
>  never-before-seen crypto monoculture in which it's possible that the
>  entire algorithm suite used by a security protocol, and the entire
>  implementation of that suite, all originate from one person.
> 
>  How on earth did it come to this?
>  [...]

Thanks. That was a good read indeed.

Just out of interest... Given that you're advocating Curve25519 for OpenPGP in your IETF draft. What do you think about ChaCha20-Poly1305 in regards as an alternative to AES-OCB?

> and watch out for his remarks on GCM.
> 
> Let me comment on Peter's statement that OCB won't be used out legal
> fears.  That might indeed be the case for License 2 (proprietary but
> non-military use) [1].  But both, License 1 (Free Software) and License
> 3 (OpenSSL), grant all rights to such software implementations of OCB
> without any restrictions.  Now, given that Free Software is one of the
> imperative features of trustworthy security software, a License 2 based
> implementation won't be trustworthy anyway.
> 
> Well, for non-software implementations one-time fees are still demanded.
> I do not consider this a major problem because by selling hardware you
> have to pay a lot of other fees as well.  Using free software on FPGAs
> would be a bit tricky but there are ways to work around with just some
> performance degradation.

But it is a problem. I love the fact that GnuPG  and OpenPGP.js are free software and they can still be used in proprietary software (at least OpenPGP.js' LGPL allows this).

By adopting OCB we would be ignoring this fact and telling other software vendors to "build free software or get out". It's not our place to make that decision for them, nor will it work. It will simply prevent then from using OCB and build forks of OpenPGP implementations without OFB. Or worse adopt a competing authenticated ciphermode that is incompatible.

For the sake of experimenting and to gain insight on the IETF draft, OpenPGP.js will go ahead and merge the AEAD pull request based on the current AES-GCM proposal. The feature will hidden behind a flag and disabled by default. But it will allow applications that do not require interoperability to opt-in and experiment with the security/performance benefits.

Once there is agreement and a finalized RFC, we will update our implementation accordingly.

> This the reason why I hope for wider adaption of OCB mode.  I do not
> want to see RC4 in new clothes in OpenPGP.

I don't buy IV reuse argument to be honest. Users of OpenPGP libraries are shielded from that potential mistake, since a new random IV is generated for them in the AEAD package before package encryption. See the following code:

https://github.com/openpgpjs/openpgpjs/blob/c8569e0cd5d6d96dab8b59faf972d144c57c8e03/src/packet/sym_encrypted_aead_protected.js#L84

Is there potential to do this wrong? Of course, but that's exactly why you use engineering best practices like code reviews and security audits for crypto libraries. Without those, there are a million other way to screw up.

Despite our disagreement on the topic, I'm enjoying the exchange and learning a lot. Looking forward to the IETF WG session :)

Tankred