[Cryptography] Derive IV from time in ticks.

[Peter Gutmann]

Phillip Hallam-Baker <phill at hallambaker.com> writes:

>Alternatively, if folk get worried about the possibility someone use GCM by
>'mistake',

GCM is simply unsafe at any speed.  Even if you try really, really hard to
make it safe, the tiniest change later on can bite you.  For example TLS,
designed by crypto experts and with a large amount of crypto expert review,
had a close call on this.  If you look at RFC 5288, "AES Galois Counter Mode
(GCM) Cipher Suites for TLS":

   The "nonce" SHALL be 12 bytes long consisting
   of two parts as follows: (this is an example of a "partially
   explicit" nonce; see Section 3.2.1 in [RFC5116]).

             struct {
                opaque salt[4];
                opaque nonce_explicit[8];
             } GCMNonce;

   The salt is the "implicit" part of the nonce and is not sent in the
   packet.  Instead, the salt is generated as part of the handshake
   process: it is either the client_write_IV (when the client is
   sending) or the server_write_IV (when the server is sending).  The
   salt length (SecurityParameters.fixed_iv_length) is 4 octets.

   The nonce_explicit is the "explicit" part of the nonce.  It is chosen
   by the sender and is carried in each TLS record in the
   GenericAEADCipher.nonce_explicit field.  The nonce_explicit length
   (SecurityParameters.record_iv_length) is 8 octets.

   Each value of the nonce_explicit MUST be distinct for each distinct
   invocation of the GCM encrypt function for any fixed key.  Failure to
   meet this uniqueness requirement can significantly degrade security.

   *** The nonce_explicit MAY be the 64-bit sequence number ***.

(my emphasis).

So if you set the nonce_explicit to the sequence number for a TLS message as
the RFC suggests, where each message is more than one AES block long, then the
GCM counter will advance faster than the TLS sequence number will.  At the
next TLS message the counter will be reset to the sequence number, resulting
in reuse of nonces.

What saves GCM in this case is that there's a second, hidden internal counter
that makes up the remainder of the nonce (not mentioned in the RFC) that
prevents nonce reuse.  If it wasn't for this hidden counter, you'd be
triggering GCM's catastrophic-failure mode on each message.

TLS 1.3, even though it changes how the AEAD nonce is constructed, makes
things even worse since it mandates the use of the TLS counter to create the
GCM counter:

  The per-record nonce for the AEAD
  construction is formed as follows:

   1.  The 64-bit record sequence number is encoded in network byte
       order and padded to the left with zeros to iv_length.

   2.  The padded sequence number is XORed with either the static
       client_write_iv or server_write_iv (depending on the role).

   The resulting quantity (of length iv_length) is used as the
   per-record nonce.

Again, it's the hidden counter that's not part of the nonce specified in the
RFC that saves GCM in TLS 1.3 from catastrophic failure.

Now, if someone were to copy either of these designs into another crypto
protocol and use what's specified as the full GCM nonce...

The solution isn't to try and fix the infixable but to specify that only a
non-catastrophic-failure-prone cipher mode be used.

Peter.