kernel/git/stable/linux.git/include/crypto/gcm.h, branch master

lib/crypto: aesgcm: Remove old AES-GCM library

2026-07-23T16:30:30+00:00

The old AES-GCM library code is no longer used, so remove it. Tested-by: Nikunj A Dadhania Reviewed-by: Ard Biesheuvel Link: https://patch.msgid.link/20260722025338.33354-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aes: Add GCM support

2026-07-22T19:01:11+00:00

Add support for AES-GCM to the crypto library. This will be used to provide streamlined implementations of the "gcm(aes)" and "rfc4106(gcm(aes))" crypto_aead algorithms. Most users of these will also be able to switch to the library, which as usual will be faster and simpler, e.g.: - drivers/net/macsec.c - fs/smb/client/ - fs/smb/server/ - net/ceph/messenger_v2.c - net/mac80211/ (for both GMAC and GCMP) - net/tipc/crypto.c - security/keys/trusted-keys/trusted_dcp.c (I've already written proof-of-concept patches for all the above, and they helped inform the API design.) As usual, the architecture-optimized AES-GCM code will be migrated into the library as well (using the hooks provided in this commit as well as the GHASH ones), eliminating lots of repetitive boilerplate code. Incremental en/decryption is supported. Incremental operation is a bit controversial in AEAD APIs because users have to be careful not to consume any decrypted data that hasn't been authenticated yet. But I do think it's the right choice here. It's not fundamentally different from the existing incremental MAC APIs, and it's the only approach that's general enough to work well for all users in the kernel: - An array of virtually-addressed buffers (like that used by BoringSSL's EVP_AEAD_CTX_sealv() and EVP_AEAD_CTX_openv()) doesn't work in the kernel in general, since in some cases the data for a single AES-GCM message is contained in a large number of highmem pages that each need to be mapped into memory individually. That can be done efficiently only by using CPU-local mappings, but there is a limited number of those. Ceph messenger v2 is a great example, as it can send or receive up to 32 MiB in a single AES-GCM message. And it needs the en/decrypted data to go into a (potentially large) number of bvecs provided by a custom iterator, as well as into four virtually-addressed buffers, two of which can be large buffers in the vmalloc region. Even just allocating an array big enough to store all the pointers can be problematic in the kernel. There are cases in which decryption runs in GFP_NOIO context or even in softirq context, where memory allocations are not as reliable as they normally are. - Meanwhile, 'struct scatterlist' (the choice of crypto_aead) has turned out to be really inconvenient for anyone who *does* just have virtually-addressed buffers. This is especially true if they can be in the vmalloc region, including the stack, as in that case the conversion to a scatterlist has to be done page-by-page. And even for users who have all of their data in bare 'struct page', none of them actually use 'struct scatterlist' as their native data structure anyway. They actually use skbs, bvecs, or other formats. - iov_iter is attractive, but ultimately not general enough either (considering the Ceph case for example), but also too general in some ways (like having support for userspace addresses). Additional iter types like ITER_SKB would help a bit, but bloating iov_iter with more types would reduce performance elsewhere in the kernel. Initial test coverage is provided by the crypto_aead support added in a later commit. I'm planning a KUnit test suite as well. Link: https://patch.msgid.link/20260715221153.246410-7-ebiggers@kernel.org Link: https://patch.msgid.link/20260722021730.16897-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aesgcm: Use GHASH library API

2026-03-23T23:44:30+00:00

Make the AES-GCM library use the GHASH library instead of directly calling gf128mul_lle(). This allows the architecture-optimized GHASH implementations to be used, or the improved generic implementation if no architecture-optimized implementation is usable. Note: this means that no longer needs to include . Remove that inclusion, and include explicitly from arch/x86/crypto/aesni-intel_glue.c which previously was relying on the transitive inclusion. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-20-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: aesgcm: Use new AES library API

2026-01-15T22:09:09+00:00

Switch from the old AES library functions (which use struct crypto_aes_ctx) to the new ones (which use struct aes_enckey). This eliminates the unnecessary computation and caching of the decryption round keys. The new AES en/decryption functions are also much faster and use AES instructions when supported by the CPU. Note that in addition to the change in the key preparation function and the key struct type itself, the change in the type of the key struct results in aes_encrypt() (which is temporarily a type-generic macro) calling the new encryption function rather than the old one. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-34-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: lib/aesgcm - Provide minimal library implementation

2022-11-11T10:14:59+00:00

Implement a minimal library version of AES-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 Link: https://lore.kernel.org/all/c6fb9b25-a4b6-2e4a-2dd1-63adda055a49@amd.com/ Signed-off-by: Ard Biesheuvel Tested-by: Nikunj A Dadhania Signed-off-by: Herbert Xu

crypto: gcm - helper functions for assoclen/authsize check

2019-08-09T05:11:41+00:00

Added inline helper functions to check authsize and assoclen for gcm, rfc4106 and rfc4543. These are used in the generic implementation of gcm, rfc4106 and rfc4543. Signed-off-by: Iuliana Prodan Signed-off-by: Herbert Xu

crypto: gcm - add GCM IV size constant

2017-09-22T09:43:08+00:00

Many GCM users use directly GCM IV size instead of using some constant. This patch add all IV size constant used by GCM. Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu