9
$\begingroup$

It seems that the nonce of AES-GCM in SSL has 3 parts:

  • salt, 4 bytes, generated in handshake, not changed in whole session
  • nonce_explicit, 8 bytes, chosen by the sender and carried in each SSL record
  • inner_counter, 4 bytes, used in AES-GCM internal

Is it possible to use a more simple method to construct the nonce:

  • generate a 16-bytes IV in handshake
  • use this IV as counter for each cipher block in the whole session life, ignore SSL record boundary

then the sender need not carry nonce for each record, saving the bandwidth.

===

I read the RFCs again and found I misunderstood something.

Let me make the question clear.

  1. AES-GCM algorithm: require the nonce is distinct.

  2. AES-GCM specification [RFC 5116]:

    • It gives an recommended format (not required):

      " When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices, as described in Section 3.2." [ Fixed + Counter ]

      " In some cases, it is desirable to not transmit or store an entire nonce, but instead to reconstruct that value from contextual information immediately prior to decryption." [ Fixed-Common + Fixed-Distinct + Counter ]

    • It is defined for protocols that uses record. I missed this before:

      "Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive, where the value P_MAX is specific to that algorithm. The value of P_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. This size is a typical upper limit for network data packets."

      QUESTION: However if we ignore the specification, is it possible to treat the whole SSL session as a stream (ignore the record bondary), and use only one nonce (and use the nonce as counter) ?

  3. AES-GCM in SSL [RFC 5288]: it uses the recommended format.

    QUESTION: since it generates master-secret in each SSL session, it would not hanppen that "multiple devices performing encryption using a single key". Why does SSL use the recommended format (the Fixed part)? What's the function of 'salt'?

I know that since specifications of AES-GCM and SSL have been defined, we should just follow it. I just wonder why it was defined like this.

Besides, maybe we could define an SSL-extension, so that the SSL client and server could use record-seq as nonce_explicit, and do not send it with record.

$\endgroup$
7
  • $\begingroup$ Maybe it's possible, but probably not. What framework/library are you talking about? If you're talking about the SSL/TLS specification, then this question is probably better suited for Information Security. $\endgroup$
    – Artjom B.
    Apr 16, 2015 at 9:35
  • $\begingroup$ @ArtjomB., I think this is fine here, as this is a question about the TLS specification, as all implementations have to follow the specification in all aspects in order to be compatible. $\endgroup$
    – SEJPM
    Apr 17, 2015 at 19:46
  • $\begingroup$ If you look at TLS 1.3 (in progress at the time of writing) then there seems to be the following topic on the mailing list: "[TLS] Consensus call on Implicit IV for AEAD". Where the main argument is about using the salt + record number as nonce, it seems - it would also remove the explicit IV value. $\endgroup$
    – Maarten Bodewes
    Apr 19, 2015 at 14:13
  • $\begingroup$ So maybe we could add an SSL-extention so that client and server using TLSv1.2 also could take record-seq as nonce. And truncate GCM's tag into smaller size. It's realy good for me to reduce the protocol-header-size of SSL record . $\endgroup$ Apr 20, 2015 at 3:59
  • $\begingroup$ @BingzhengWu The tag size of GCM is a rather security sensitive part of the algorithm, it should only be altered with extreme care. $\endgroup$
    – Maarten Bodewes
    Apr 20, 2015 at 11:35

2 Answers 2

8
$\begingroup$

This is a trickier question than you might think.

The first thing to note is that your scheme doesn't respect record boundaries. TLS 1.2 seems to have been rewritten to use a random IV for CBC mode encryption for each record (to avoid certain attacks). It is therefore likely that the idea of TLS 1.2 is to respect record boundaries.

The document "AES Galois Counter Mode (GCM) Cipher Suites for TLS" - RFC 5288 - mentions "An Interface and Algorithms for Authenticated Encryption" - RFC 5116. This document specifies the use of a 4 byte salt and 8 byte random. That means that the nonce is 12 bytes total, consisting of the persistent part of 4 bytes and 8 bytes random. The GCM specification strongly recommends a 12 byte (96 bit) nonce/IV. This specification in turn is based on GCM ESP, RFC 4106, which specifies the use of GCM for IPsec. So in general the use of GCM in TLS 1.2 seems to follow previously established standards.

The specification of a per record random (explicit) part is of course in line with the cipher suites that use CBC based encryption. In this case however the IV only has to be 8 bytes instead of 16, which saves some 8 bytes as overhead. That's still 8 bytes more than your proposed scheme - which, again, doesn't respect record boundaries - but it's better than CBC.

Notes:

  • If you would change to a fully implicit nonce you should still keep to 12 bytes to keep within the GCM specifications. If you would specify 16 bytes IV then the GCM specification requires an additional GMAC. There seems to be no way of specifying a 16 byte counter to be used; the 4 least significant (rightmost) bytes are set by the algorithm itself.
  • Related, in your scheme it is impossible to use a GCM API that only allows 12 byte nonces (i.e. without the counter included in the IV). You would need some way of keeping track of the counter and a method of instantiating GCM with that full 16 byte counter.
  • In your scheme it would be impossible to parallelize encryption/authentication and decryption/verification unless you had a way to pre-compute the record payload.

In conclusion, although your scheme could work (it's more efficient and isn't likely to be insecure), it doesn't respect record boundaries and it would put additional requirements on the GCM library. Finally, it would not follow pre-established standards for the use of GCM in a transport protocol.

In TLS 1.3 (under construction at the time of writing) it seems that the record number may be used instead of the explicit random, which would require less overhead in the record header and less calls to the random generator.


Note that Figure 2 in RFC 5116 "An Interface and Algorithms for Authenticated Encryption" includes the counter in the nonce specification. I've made a report for an ERRATA on this as the GCM specification and the ESP documents both treat the nonce as a 12 byte value (so without the counter).

$\endgroup$
6
  • 1
    $\begingroup$ I've left out the "I don't know, because I didn't design it" part, I guess that's kind of implied. $\endgroup$
    – Maarten Bodewes
    Apr 19, 2015 at 13:58
  • $\begingroup$ CBC mode need IV for each record because the IV should be unpredictable . However the CTR (or GCM) mode does not require that. So I do not think respecting to record boundary in CBC means we should also respect in GCM mode. $\endgroup$ Apr 20, 2015 at 3:35
  • $\begingroup$ I just read the nonce part in rfc5116, and missed the API spec part, which define the nonce is 12bytes in AEAD_AES_xxx_GCM. Thanks. $\endgroup$ Apr 20, 2015 at 3:42
  • $\begingroup$ Small point: It was TLS1.1 (rfc4346) that added unpredictable-IV-per-record for CBC, blocking Vaudenay and later BEAST. (Although nearly everybody did 1/n fragmentation to block BEAST even in SSL3 and TLS1.0, back before POODLE made at least SSL3 untenable.) $\endgroup$ May 1, 2015 at 11:16
  • 1
    $\begingroup$ @SEJPM Thanks for the update, but isn't that what's already in the answer (first to last paragraph)? $\endgroup$
    – Maarten Bodewes
    Jul 2, 2015 at 11:37
-1
$\begingroup$

I just quickly read the TLS specification and the document that introduces GCM into TLS.

It is stated in the definition of GCM-ciphersuites that a 12-byte nonce is supplied (8 bytes per packet and 4 bytes from the handshake, as you correctly stated).

First I'd like to say:
Very often there's a (very good) reason why a decision was made (like here) in something such important as TLS.

Technically your approach would work. (although not accepting record boundaries isn't nice. Maybe cut the stream at the end of a record and increment counter)

Now I'll tell you why TLS doesn't go with something like you proposed but rather with this system:
TLS also has to support CBC mode. (for legacy reasons :-( )
And as the protocol must be very similar for all ciphersuites (no matter wether CBC / GCM / ...) it must provide the most robust IV it can provide (as CBC strongly relies on unpredictable IVs and not just unique ones).

Now let's assume your scheme to work with CBC. You'd ignore record boundaries and hence (in most cases) the delivery and verification of a message has to wait until the next message was delivered, so it's common practice to give each message / record an own IV. But even a continous keystream isn't nice. It introduces dependecies between the messages you want to avoid. You want to be able to read any message if you know the key. If you'd make the IV secret you'd just have an extended key, which isn't a security risk, but might bring practical issues. Now the salt seems to be used to guarantee that IVs are unpredictable (as required by CBC), as an attacker can't know the salt in any case. As 32-bit randomness are fine to make an IV unpredictable the other 64-bits (to 96-bits) are generated separately (at random) for each message. (making it even more unpredictable) However GCM-TLS-Ciphersuite-Documentation allows usage of a counter in TLS (it was for packets I think) to be used as the 64-bit part, so we are back at your proposal which is (somehow) in TLS.

The reason I gave here are only good guesses. To find the real reasons behind all design decisions of TLS one would have to dig through thousands of mails in the archive of the IETF.

$\endgroup$
2
  • $\begingroup$ That's a nice text, however in versions prior to TLS 1.2 it seemed that the previous block was used, and in TLS 1.2 it specifies opaque IV[SecurityParameters.record_iv_length] where the IV length is identical to the block size. In other words, the CBC mode encryption doesn't use this construct at all. $\endgroup$
    – Maarten Bodewes
    Apr 19, 2015 at 11:41
  • $\begingroup$ 1. you say "not accepting record boundaries isn't nice", but I don't understand your reason. 2. The IV is defined only for CBC mode in SSL, so i don't think it's the reason why add an IV/nonce in each record in GCM mode. $\endgroup$ Apr 20, 2015 at 3:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.