kernel/linux.git/crypto/hmac.c, branch v6.19.11

crypto: hmac - Add ahash support

2025-05-19T05:48:20+00:00

Add ahash support to hmac so that drivers that can't do hmac in hardware do not have to implement duplicate copies of hmac. Signed-off-by: Herbert Xu

crypto: hmac - Add export_core and import_core

2025-05-19T05:48:19+00:00

Add export_import and import_core so that hmac can be used as a fallback by block-only drivers. Signed-off-by: Herbert Xu

crypto: hmac - Zero shash desc in setkey

2025-05-19T05:48:19+00:00

The shash desc needs to be zeroed after use in setkey as it is not finalised (finalisation automatically zeroes it). Also remove the final function as it's been superseded by finup. Signed-off-by: Herbert Xu

Revert "crypto: run initcalls for generic implementations earlier"

2025-05-05T10:20:44+00:00

This reverts commit c4741b23059794bd99beef0f700103b0d983b3fd. Crypto API self-tests no longer run at registration time and now occur either at late_initcall or upon the first use. Therefore the premise of the above commit no longer exists. Revert it and subsequent additions of subsys_initcall and arch_initcall. Note that lib/crypto calls will stay at subsys_initcall (or rather downgraded from arch_initcall) because they may need to occur before Crypto API registration. Signed-off-by: Herbert Xu

crypto: hmac - Make descsize an algorithm attribute

2025-04-16T07:36:24+00:00

Rather than setting descsize in init_tfm, make it an algorithm attribute and set it during instance construction. Signed-off-by: Herbert Xu

crypto: hmac - remove unnecessary alignment logic

2023-10-27T10:04:24+00:00

The hmac template is setting its alignmask to that of its underlying unkeyed hash algorithm, and it is aligning the ipad and opad fields in its tfm context to that alignment. However, hmac does not actually need any sort of alignment itself, which makes this pointless except to keep the pads aligned to what the underlying algorithm prefers. But very few shash algorithms actually set an alignmask, and it is being removed from those remaining ones; also, after setkey, the pads are only passed to crypto_shash_import and crypto_shash_export which ignore the alignmask. Therefore, make the hmac template stop setting an alignmask and simply use natural alignment for ipad and opad. Note, this change also moves the pads from the beginning of the tfm context to the end, which makes much more sense; the variable-length fields should be at the end. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: hmac - Add missing blank line

2023-06-16T12:30:35+00:00

The following checkpatch warning has been fixed: - WARNING: Missing a blank line after declarations Signed-off-by: Franziska Naepelt Signed-off-by: Herbert Xu

crypto: hmac - Add support for cloning

2023-04-20T10:20:04+00:00

Allow hmac to be cloned. The underlying hash can be used directly with a reference count. Signed-off-by: Herbert Xu

crypto: hmac - disallow keys < 112 bits in FIPS mode

2022-02-11T09:22:01+00:00

FIPS 140 requires a minimum security strength of 112 bits. This implies that the HMAC key must not be smaller than 112 in FIPS mode. This restriction implies that the test vectors for HMAC that have a key that is smaller than 112 bits must be disabled when FIPS support is compiled. Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: algapi - use common mechanism for inheriting flags

2020-07-16T11:49:08+00:00

The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a template is instantiated, the template will have CRYPTO_ALG_ASYNC set if any of the algorithms it uses has CRYPTO_ALG_ASYNC set. We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets "inherited" in the same way. This is difficult because the handling of CRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by: - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that have these inheritance semantics. - Add crypto_algt_inherited_mask(), for use by template ->create() methods. It returns any of these flags that the user asked to be unset and thus must be passed in the 'mask' to crypto_grab_*(). - Also modify crypto_check_attr_type() to handle computing the 'mask' so that most templates can just use this. - Make crypto_grab_*() propagate these flags to the template instance being created so that templates don't have to do this themselves. Make crypto/simd.c propagate these flags too, since it "wraps" another algorithm, similar to a template. Based on a patch by Mikulas Patocka (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com). Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu