Changes in gf128hash.c

370c3883195566ee3e7d79e0146c3d735a406573 - Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux

Tue, 14 Apr 2026 02:31:39 +0200

Merge tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linuxPull crypto library updates from Eric Biggers: - Migrate more hash algorithms from the traditional crypto subsystem to lib/crypto/ Like the algorithms migrated earlier (e.g. SHA-*), this simplifies the implementations, improves performance, enables further simplifications in calling code, and solves various other issues: - AES CBC-based MACs (AES-CMAC, AES-XCBC-MAC, and AES-CBC-MAC) - Support these algorithms in lib/crypto/ using the AES library and the existing arm64 assembly code - Reimplement the traditional crypto API's "cmac(aes)", "xcbc(aes)", and "cbcmac(aes)" on top of the library - Convert mac80211 to use the AES-CMAC library. Note: several other subsystems can use it too and will be converted later - Drop the broken, nonstandard, and likely unused support for "xcbc(aes)" with key lengths other than 128 bits - Enable optimizations by default - GHASH - Migrate the standalone GHASH code into lib/crypto/ - Integrate the GHASH code more closely with the very similar POLYVAL code, and improve the generic GHASH implementation to resist cache-timing attacks and use much less memory - Reimplement the AES-GCM library and the "gcm" crypto_aead template on top of the GHASH library. Remove "ghash" from the crypto_shash API, as it's no longer needed - Enable optimizations by default - SM3 - Migrate the kernel's existing SM3 code into lib/crypto/, and reimplement the traditional crypto API's "sm3" on top of it - I don't recommend using SM3, but this cleanup is worthwhile to organize the code the same way as other algorithms - Testing improvements: - Add a KUnit test suite for each of the new library APIs - Migrate the existing ChaCha20Poly1305 test to KUnit - Make the KUnit all_tests.config enable all crypto library tests - Move the test kconfig options to the Runtime Testing menu - Other updates to arch-optimized crypto code: - Optimize SHA-256 for Zhaoxin CPUs using the Padlock Hash Engine - Remove some MD5 implementations that are no longer worth keeping - Drop big endian and voluntary preemption support from the arm64 code, as those configurations are no longer supported on arm64 - Make jitterentropy and samples/tsm-mr use the crypto library APIs* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (66 commits) lib/crypto: arm64: Assume a little-endian kernel arm64: fpsimd: Remove obsolete cond_yield macro lib/crypto: arm64/sha3: Remove obsolete chunking logic lib/crypto: arm64/sha512: Remove obsolete chunking logic lib/crypto: arm64/sha256: Remove obsolete chunking logic lib/crypto: arm64/sha1: Remove obsolete chunking logic lib/crypto: arm64/poly1305: Remove obsolete chunking logic lib/crypto: arm64/gf128hash: Remove obsolete chunking logic lib/crypto: arm64/chacha: Remove obsolete chunking logic lib/crypto: arm64/aes: Remove obsolete chunking logic lib/crypto: Include instead of lib/crypto: aesgcm: Don't disable IRQs during AES block encryption lib/crypto: aescfb: Don't disable IRQs during AES block encryption lib/crypto: tests: Migrate ChaCha20Poly1305 self-test to KUnit lib/crypto: sparc: Drop optimized MD5 code lib/crypto: mips: Drop optimized MD5 code lib: Move crypto library tests to Runtime Testing menu crypto: sm3 - Remove 'struct sm3_state' crypto: sm3 - Remove the original "sm3_block_generic()" crypto: sm3 - Remove sm3_base.h ... List of files: /linux/lib/crypto/gf128hash.c

c417e7045b70345f59643fb2db67b0e7fbd7fbd0 - lib/crypto: gf128hash: Add GHASH support

Thu, 19 Mar 2026 07:17:04 +0100

lib/crypto: gf128hash: Add GHASH supportAdd GHASH support to the gf128hash module.This will replace the GHASH support in the crypto_shash API. It will beused by the "gcm" template and by the AES-GCM library (when anarch-optimized implementation of the full AES-GCM is unavailable).This consists of a simple API that mirrors the existing POLYVAL API, ageneric implementation of that API based on the existing efficient andside-channel-resistant polyval_mul_generic(), and the framework forarchitecture-optimized implementations of the GHASH functions.The GHASH accumulator is stored in POLYVAL format rather than GHASHformat, since this is what most modern GHASH implementations actuallyneed. The few implementations that expect the accumulator in GHASHformat will just convert the accumulator to/from GHASH formattemporarily. (Supporting architecture-specific accumulator formatswould be possible, but doesn't seem worth the complexity.)However, architecture-specific formats of struct ghash_key will besupported, since a variety of formats will be needed there anyway. Thedefault format is just the key in POLYVAL format.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-4-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/gf128hash.c

b3b6e8f9b38911e9b30a5abe845541ade0797327 - lib/crypto: gf128hash: Support GF128HASH_ARCH without all POLYVAL functions

Thu, 19 Mar 2026 07:17:03 +0100

lib/crypto: gf128hash: Support GF128HASH_ARCH without all POLYVAL functionsCurrently, some architectures (arm64 and x86) have optimized code forboth GHASH and POLYVAL. Others (arm, powerpc, riscv, and s390) haveoptimized code only for GHASH. While POLYVAL support could beimplemented on these other architectures, until then we need to supportthe case where arch-optimized functions are present only for GHASH.Therefore, update the support for arch-optimized POLYVAL functions toallow architectures to opt into supporting these functions individually.The new meaning of CONFIG_CRYPTO_LIB_GF128HASH_ARCH is that some levelof GHASH and/or POLYVAL acceleration is provided.Also provide an implementation of polyval_mul() based onpolyval_blocks_arch(), for when polyval_mul_arch() isn't implemented.Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-3-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/gf128hash.c

61f66c5216a961784b12307be60a25204525605c - lib/crypto: gf128hash: Rename polyval module to gf128hash

Thu, 19 Mar 2026 07:17:02 +0100

lib/crypto: gf128hash: Rename polyval module to gf128hashCurrently, the standalone GHASH code is coupled with crypto_shash. Thishas resulted in unnecessary complexity and overhead, as well as the codebeing unavailable to library code such as the AES-GCM library. Like wasdone with POLYVAL, it needs to find a new home in lib/crypto/.GHASH and POLYVAL are closely related and can each be implemented interms of each other. Optimized code for one can be reused with theother. But also since GHASH tends to be difficult to implement directlydue to its unnatural bit order, most modern GHASH implementations(including the existing arm, arm64, powerpc, and x86 optimized GHASHcode, and the new generic GHASH code I'll be adding) actuallyreinterpret the GHASH computation as an equivalent POLYVAL computation,pre and post-processing the inputs and outputs to map to/from POLYVAL.Given this close relationship, it makes sense to group the GHASH andPOLYVAL code together in the same module. This gives us a wide range ofoptions for implementing them, reusing code between the two and properlyutilizing whatever instructions each architecture provides.Thus, GHASH support will be added to the library module that iscurrently called "polyval". Rename it to an appropriate name:"gf128hash". Rename files, options, functions, etc. where appropriateto reflect the upcoming sharing with GHASH. (Note: polyval_kunit is notrenamed, as ghash_kunit will be added alongside it instead.)Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260319061723.1140720-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux/lib/crypto/gf128hash.c