crypto: gcm - Provide minimal library implementation

Implement a minimal library version of GCM based on the existing library implementations of AES and multiplication in GF(2^128). Using these primitives, GCM can be implemented in a straight-forward manner.

GCM has a couple of sharp edges, i.e., the amount of input data processed with the same initialization vector (IV) should be capped to protect the counter from 32-bit rollover (or carry), and the size of the authentication tag should be fixed for a given key. [0]

The former concern is addressed trivially, given that the function call API uses 32-bit signed types for the input lengths. It is still up to the caller to avoid IV reuse in general, but this is not something we can police at the implementation level.

As for the latter concern, let's make the authentication tag size part of the key schedule, and only permit it to be configured as part of the key expansion routine.

Note that table based AES implementations are susceptible to known plaintext timing attacks on the encryption key. The AES library already attempts to mitigate this to some extent, but given that the counter mode encryption used by GCM operates exclusively on known plaintext by construction (the IV and therefore the initial counter value are known to an attacker), let's take some extra care to mitigate this, by calling the AES library with interrupts disabled.

[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf

Cc "Nikunj A. Dadhania" <[email protected]>

Link https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Ard Biesheuvel <[email protected]>

---

lib/crypto/gcm.c new file +20 -0

+/**
+ * gcm_decrypt - Perform GCM decryption on a block of data
+ * @ctx:	The GCM key schedule
+ * @dst:	Pointer to the plaintext output buffer
+ * @src:	Pointer the ciphertext (may equal @dst for decryption in place)
+ * @crypt_len:	The size in bytes of the plaintext and ciphertext.
+ * @assoc:	Pointer to the associated data,
+ * @assoc_len:	The size in bytes of the associated data
+ * @iv:		The initialization vector (IV) to use for this block of data
+ *		(must be 12 bytes in size as per the GCM spec recommendation)
+ * @authtag:	The address of the buffer in memory where the authentication
+ *		tag is stored.
+ *
+ * Returns 0 on success, or -EBADMSG if the ciphertext failed authentication.
+ * On failure, no plaintext will be returned.
+ */
+int __must_check gcm_decrypt(const struct gcm_ctx *ctx, u8 *dst, const u8 *src,
+			     int crypt_len, const u8 *assoc, int assoc_len,
+			     const u8 iv[GCM_AES_IV_SIZE], const u8 *authtag)
+{

Hi Ard,

Quoted 58 lines · Ard Biesheuvel

Implement a minimal library version of GCM based on the existing library implementations of AES and multiplication in GF(2^128). Using these primitives, GCM can be implemented in a straight-forward manner.

GCM has a couple of sharp edges, i.e., the amount of input data processed with the same initialization vector (IV) should be capped to protect the counter from 32-bit rollover (or carry), and the size of the authentication tag should be fixed for a given key. [0]

The former concern is addressed trivially, given that the function call API uses 32-bit signed types for the input lengths. It is still up to the caller to avoid IV reuse in general, but this is not something we can police at the implementation level.

As for the latter concern, let's make the authentication tag size part of the key schedule, and only permit it to be configured as part of the key expansion routine.

Note that table based AES implementations are susceptible to known plaintext timing attacks on the encryption key. The AES library already attempts to mitigate this to some extent, but given that the counter mode encryption used by GCM operates exclusively on known plaintext by construction (the IV and therefore the initial counter value are known to an attacker), let's take some extra care to mitigate this, by calling the AES library with interrupts disabled.

[0] https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf

Cc "Nikunj A. Dadhania" <[email protected]>

Link https://lore.kernel.org/all/[email protected]/ open here

Signed-off-by Ard Biesheuvel <[email protected]>

---

lib/crypto/gcm.c new file +26 -0

+/**
+ * gcm_decrypt - Perform GCM decryption on a block of data
+ * @ctx:     The GCM key schedule
+ * @dst:     Pointer to the plaintext output buffer
+ * @src:     Pointer the ciphertext (may equal @dst for decryption in place)
+ * @crypt_len:       The size in bytes of the plaintext and ciphertext.
+ * @assoc:   Pointer to the associated data,
+ * @assoc_len:       The size in bytes of the associated data
+ * @iv:              The initialization vector (IV) to use for this block of data
+ *           (must be 12 bytes in size as per the GCM spec recommendation)
+ * @authtag: The address of the buffer in memory where the authentication
+ *           tag is stored.
+ *
+ * Returns 0 on success, or -EBADMSG if the ciphertext failed authentication.
+ * On failure, no plaintext will be returned.
+ */
+int __must_check gcm_decrypt(const struct gcm_ctx *ctx, u8 *dst, const u8 *src,
+                          int crypt_len, const u8 *assoc, int assoc_len,
+                          const u8 iv[GCM_AES_IV_SIZE], const u8 *authtag)
+{
+     u8 tagbuf[AES_BLOCK_SIZE];
+     __be32 ctr[4];
+
+     memcpy(ctr, iv, GCM_AES_IV_SIZE);
+
+     gcm_mac(ctx, src, crypt_len, assoc, assoc_len, ctr, tagbuf);

lib/crypto/gcm.c line 166

Quoted 4 lines

lib/crypto/gcm.c new file +4 -0

+     if (crypto_memneq(authtag, tagbuf, ctx->authsize)) {
+             memzero_explicit(tagbuf, sizeof(tagbuf));
+             return -EBADMSG;
+     }

The gcm_mac computation seems to be broken in this version. When I receive the encrypted packet back from the security processor the authtag does not match. Will debug further and report back.

Quoted 62 lines · Nikunj A. Dadhania

Hi Ard,

Quoted 58 lines · Ard Biesheuvel

Implement a minimal library version of GCM based on the existing library implementations of AES and multiplication in GF(2^128). Using these primitives, GCM can be implemented in a straight-forward manner.

GCM has a couple of sharp edges, i.e., the amount of input data processed with the same initialization vector (IV) should be capped to protect the counter from 32-bit rollover (or carry), and the size of the authentication tag should be fixed for a given key. [0]

The former concern is addressed trivially, given that the function call API uses 32-bit signed types for the input lengths. It is still up to the caller to avoid IV reuse in general, but this is not something we can police at the implementation level.

As for the latter concern, let's make the authentication tag size part of the key schedule, and only permit it to be configured as part of the key expansion routine.

Note that table based AES implementations are susceptible to known plaintext timing attacks on the encryption key. The AES library already attempts to mitigate this to some extent, but given that the counter mode encryption used by GCM operates exclusively on known plaintext by construction (the IV and therefore the initial counter value are known to an attacker), let's take some extra care to mitigate this, by calling the AES library with interrupts disabled.

[0] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2Flegacy%2Fsp%2Fnistspecialpublication800-38d.pdf&amp;data=05%7C01%7Cnikunj.dadhania%40amd.com%7C912c5b73be0146ca63db08daaa97ade4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638009869061457627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=sNHrpE3d7w%2BpT8dzAPiFbmvYLLIu9zsCnJ%2BFFxjzp%2Bk%3D&amp;reserved=0

Cc "Nikunj A. Dadhania" <[email protected]>

Link https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2Fc6fb9b25-a4b6-2e4a-2dd1-63adda055a49%40amd.com%2F&amp;data=05%7C01%7Cnikunj.dadhania%40amd.com%7C912c5b73be0146ca63db08daaa97ade4%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638009869061457627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=oyUKkikTm6wsPy8vFHiS98TZpL4Hu%2BFz9aYX%2Fs37wk0%3D&amp;reserved=0

Signed-off-by Ard Biesheuvel <[email protected]>

---

lib/crypto/gcm.c new file +26 -0

+/**
+ * gcm_decrypt - Perform GCM decryption on a block of data
+ * @ctx:     The GCM key schedule
+ * @dst:     Pointer to the plaintext output buffer
+ * @src:     Pointer the ciphertext (may equal @dst for decryption in place)
+ * @crypt_len:       The size in bytes of the plaintext and ciphertext.
+ * @assoc:   Pointer to the associated data,
+ * @assoc_len:       The size in bytes of the associated data
+ * @iv:              The initialization vector (IV) to use for this block of data
+ *           (must be 12 bytes in size as per the GCM spec recommendation)
+ * @authtag: The address of the buffer in memory where the authentication
+ *           tag is stored.
+ *
+ * Returns 0 on success, or -EBADMSG if the ciphertext failed authentication.
+ * On failure, no plaintext will be returned.
+ */
+int __must_check gcm_decrypt(const struct gcm_ctx *ctx, u8 *dst, const u8 *src,
+                          int crypt_len, const u8 *assoc, int assoc_len,
+                          const u8 iv[GCM_AES_IV_SIZE], const u8 *authtag)
+{
+     u8 tagbuf[AES_BLOCK_SIZE];
+     __be32 ctr[4];
+
+     memcpy(ctr, iv, GCM_AES_IV_SIZE);
+
+     gcm_mac(ctx, src, crypt_len, assoc, assoc_len, ctr, tagbuf);

Quoted 9 lines

lib/crypto/gcm.c line 166

Quoted 4 lines

lib/crypto/gcm.c new file +4 -0

+     if (crypto_memneq(authtag, tagbuf, ctx->authsize)) {
+             memzero_explicit(tagbuf, sizeof(tagbuf));
+             return -EBADMSG;
+     }

The gcm_mac computation seems to be broken in this version. When I receive the encrypted packet back from the security processor the authtag does not match. Will debug further and report back.

Sorry to hear that. If you find out what's wrong, can you please provide a test vector that reproduces it so we can add it to the list?

Quoted 35 lines · Ard Biesheuvel

Quoted 34 lines · Nikunj A. Dadhania

Hi Ard,

Quoted 30 lines · Ard Biesheuvel

Implement a minimal library version of GCM based on the existing library implementations of AES and multiplication in GF(2^128). Using these primitives, GCM can be implemented in a straight-forward manner.

GCM has a couple of sharp edges, i.e., the amount of input data processed with the same initialization vector (IV) should be capped to protect the counter from 32-bit rollover (or carry), and the size of the authentication tag should be fixed for a given key. [0]

The former concern is addressed trivially, given that the function call API uses 32-bit signed types for the input lengths. It is still up to the caller to avoid IV reuse in general, but this is not something we can police at the implementation level.

As for the latter concern, let's make the authentication tag size part of the key schedule, and only permit it to be configured as part of the key expansion routine.

Note that table based AES implementations are susceptible to known plaintext timing attacks on the encryption key. The AES library already attempts to mitigate this to some extent, but given that the counter mode encryption used by GCM operates exclusively on known plaintext by construction (the IV and therefore the initial counter value are known to an attacker), let's take some extra care to mitigate this, by calling the AES library with interrupts disabled.

Cc "Nikunj A. Dadhania" <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---

Quoted 7 lines

Quoted 4 lines

The gcm_mac computation seems to be broken in this version. When I receive the encrypted packet back from the security processor the authtag does not match. Will debug further and report back.

Sorry to hear that. If you find out what's wrong, can you please provide a test vector that reproduces it so we can add it to the list?

My bad, it was wrong crypt_len that I was sending. Working fine now.

Tested-by Nikunj A Dadhania <[email protected]>