GCM Restrictions, Birthday Problems, and IBM MQ

By Tim Zielke posted Fri May 22, 2020 10:27 AM


GCM Restrictions, Birthday Problems, and IBM MQ


You may be wondering what GCM (Galois/Counter Mode), birthdays (actually the Birthday Problem/Paradox in probability theory), and IBM MQ have in common.  This blog post will lay the foundation on why I believe the 2^32 TLS record restriction for GCM that is documented in the “Enabling Cipherspecs” section of the IBM 9.1 manual does not apply to TLS (and subsequently IBM MQ TLS) for either mainframe or distributed.  Along the way we will touch on all three topics.



NIST GCM Restriction in the IBM MQ Manual


In the “Enabling Cipherspecs” section of the IBM MQ 9.1 manual, there is this note about GCM (Galois/Counter Mode) ciphersuites.


“Following a recommendation by NIST, GCM CipherSpecs have a restriction which means that after 2ˆ32 TLS records are sent, using the same session key, the connection is terminated with message AMQ9288.

To prevent this error from happening: avoid using GCM Ciphers, enable secret key reset, or start your IBM MQ queue manager with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set.


This restriction does not apply to IBM MQ for z/OS®.”



A TLS record is how encrypted data is sent between the TLS client and server.  So for distributed MQ, if you are using a GCM ciphersuite (e.g. ECDHE_ECDSA_AES_128_GCM_SHA256) and you send more than 2^32 TLS records for the same session key, the default behavior is to break the MQ connection with an AMQ9288 error.  Note too that for the mainframe it simply states “this restriction does not apply”.


Now the following gets very technical, but it is needed to explain the argument.  It also goes without saying that an IBM MQ customer should follow the explicit advice of the IBM MQ manual, until it is changed.  However, the IBM MQ manual does give you the option when using GCM ciphersuites for distributed “or start your IBM MQ queue manager with the environment variable GSK_ENFORCE_GCM_RESTRICTION=GSK_FALSE set”.  An IBM MQ customer may feel more comfortable using this approach after reading this argument and having it validated by their appropriate security professionals and IBM MQ support.



NIST GCM Restriction


I believe the NIST GCM restriction that the MQ manual refers to comes from the 8.3 section “Constraints on the Number of Invocations” in the NIST SP 800-38D document “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC”. 


“8.3 Constraints on the Number of Invocations


The following requirement applies to all implementations that use either 1) the deterministic

construction with IVs whose length is not 96, or 2) the RBG-based construction, for IVs of any

length. In other words, unless an implementation only uses 96-bit IVs that are generated by the

deterministic construction:


The total number of invocations of the authenticated encryption function shall not exceed

2^32, including all IV lengths and all instances of the authenticated encryption function with

the given key.”



Now the above blurb is very technical, but here is a breakdown of what it is saying.  In order to perform a GCM encryption invocation, you need to pass in an IV (Initialization Vector) which must be unique.  This NIST GCM restriction is warning about not exceeding 2^32 invocations for GCM, but it does have a caveat where the restriction does not apply, “unless an implementation only uses 96-bit IVs that are generated by the deterministic construction”.  We will see in the next section that the standard way TLS implements GCM IVs is through a 96-bit IV that is generated by deterministic construction (i.e. through the TLS sequence number).





We find how TLS build the GCM IVs (or nonces) in this RFC ->


The nonce is 96 bit (or 12 bytes):


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;


And the nonce_explicit is deterministic and more than likely set to the 8-byte TLS sequence number:


   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.


Therefore, a TLS GCM IV implementation would normally be implemented in a way where the 2^32 invocation limitation would not apply.  If you read the entire NIST SP 800-38D document 8.3 section, you can deduce that TLS GCM would then be safe for 2^64 invocations or TLS records.



The Birthday Problem


So why does the NIST SP 800-38D document have this 2^32 invocation limit for some of the ways that the GCM IV is constructed?  It has more to do with when the IV is being randomly generated and involves the Birthday Problem ->


As this link states, “In probability theory, the birthday problem or birthday paradox concerns the probability that, in a set of n randomly chosen people, some pair of them will have the same birthday.”  One interesting fact from the Birthday Problem is that if there are only 23 people in a room, there is a 50% chance that at least two of them have the same birthday!  So if you are ever in a room with more than 23 people and you like bets that are in your favor, you have a more than 50% chance of winning the bet “Hey buddy, I bet there are at least two people in this room that have the same birthday”.


The Birthday Problem (or Paradox) shows that it can be unintuitive how high the percentage is for duplicates under certain random situations.  The Birthday Problem is also a reason why NIST recommends a limitation of 2^32 invocations for GCM IVs that are randomly generated.





A lot of this information was very technical.  However, hopefully it helped lay the foundation of why I believe that TLS (and subsequently IBM MQ TLS) is not restricted to the NIST GCM 2^32 invocation limitation.  Obviously, the above statement is something for security professionals (which I am not) and IBM MQ to analyze and confirm, before being used in practice.





8 days ago

I did raise a PMR for the points in this blog post.  The PMR ended with the recommendation for an RFE to be raised for any implicit key resets by IBM MQ.  Here is the RFE for people to vote for.

RFE 140976 - Implicit Key Reset for TLS CipherSuites Reaching Upper Bound of Secure Data Sent

As noted in the comments of the RFE, the TLS 1.3 RFC 8446 does put the onus on the TLS implementer (e.g. gskit) to do implicit key resets for any relevant security limits that are being reached.  From section 5.5 of RFC 8446:

"There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.
Implementations SHOULD do a key update as described in Section 4.6.3 prior to reaching these limits." 

I also did not receive any technical rebuttal in the PMR to the points raised in this blog about this NIST recommendation of not exceeding 2^32 TLS invocations for a given key not applying to TLS GCM.  I personally feel the points raised in this blog post still stand, for whatever that is worth. :-)

Tue June 02, 2020 06:00 AM

Thanks Mark - be good to have something at that URL since it is out there now.

Wed May 27, 2020 05:20 AM

Re: | When initially written, that item had been planned to be internal only ; however, now until a determination is made on the applicability of the restriction mentioned in this blog, the item may be externalized again (with revisions) pending any word from MQ Development on the points raised by this blog

Tue May 26, 2020 08:10 PM

Does this blog post have anything to do with why the IBM Support Doc "GCM CipherSpecs AMQ9288E and the Applicability of the NIST restriction on z/OS MQ (for SSL Key Resets)" at has disappeared?

Tue May 26, 2020 08:43 AM

Interesting reading. Thanks Tim