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

[Werner Koch]

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.

> 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?
  [...]
  
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.

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


Shalom-Salam,

   Werner


[1] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.