kernel/linux.git/security/keys/encrypted-keys/encrypted.c, branch v7.0-rc7

kernel.h: drop hex.h and update all hex.h users

2026-01-21T03:44:19+00:00

Remove from and update all users/callers of hex.h interfaces to directly #include as part of the process of putting kernel.h on a diet. Removing hex.h from kernel.h means that 36K C source files don't have to pay the price of parsing hex.h for the roughly 120 C source files that need it. This change has been build-tested with allmodconfig on most ARCHes. Also, all users/callers of in the entire source tree have been updated if needed (if not already #included). Link: https://lkml.kernel.org/r/20251215005206.2362276-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Reviewed-by: Andy Shevchenko Cc: Ingo Molnar Cc: Yury Norov (NVIDIA) Signed-off-by: Andrew Morton

keys: Remove redundant less-than-zero checks

2025-11-27T21:50:20+00:00

The local variables 'size_t datalen' are unsigned and cannot be less than zero. Remove the redundant conditions. Signed-off-by: Thorsten Blum Reviewed-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen

KEYS: encrypted: Use SHA-256 library instead of crypto_shash

2025-10-04T14:25:35+00:00

Instead of the "sha256" crypto_shash, just use sha256(). Similarly, instead of the "hmac(sha256)" crypto_shash, just use hmac_sha256_usingrawkey(). This is simpler and faster. Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Reviewed-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen

KEYS: encrypted: add missing MODULE_DESCRIPTION()

2024-07-01T14:16:54+00:00

During kbuild, with W=1, modpost will warn when a module doesn't have a MODULE_DESCRIPTION(). The encrypted-keys module does not have a MODULE_DESCRIPTION(). But currently, even with an allmodconfig configuration, this module is built-in, and as a result, kbuild does not currently warn about the missing MODULE_DESCRIPTION(). However, just in case it is built as a module in the future, add the missing MODULE_DESCRIPTION() macro invocation. Signed-off-by: Jeff Johnson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

Revert "KEYS: encrypted: Add check for strsep"

2024-01-24T21:11:59+00:00

This reverts commit b4af096b5df5dd131ab796c79cedc7069d8f4882. New encrypted keys are created either from kernel-generated random numbers or user-provided decrypted data. Revert the change requiring user-provided decrypted data. Reported-by: Vishal Verma Signed-off-by: Mimi Zohar

KEYS: encrypted: Add check for strsep

2023-11-27T17:44:47+00:00

Add check for strsep() in order to transfer the error. Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Signed-off-by: Chen Ni Signed-off-by: Mimi Zohar

KEYS: encrypted: Do not include crypto/algapi.h

2023-09-15T10:30:43+00:00

The header file crypto/algapi.h is for internal use only. Use the header file crypto/utils.h instead. Acked-by: Mimi Zohar Signed-off-by: Herbert Xu

KEYS: encrypted: fix key instantiation with user-provided data

2022-10-19T17:01:23+00:00

Commit cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") added key instantiation with user provided decrypted data. The user data is hex-ascii-encoded but was just memcpy'ed to the binary buffer. Fix this to use hex2bin instead. Old keys created from user provided decrypted data saved with "keyctl pipe" are still valid, however if the key is recreated from decrypted data the old key must be converted to the correct format. This can be done with a small shell script, e.g.: BROKENKEY=abcdefABCDEF1234567890aaaaaaaaaa NEWKEY=$(echo -ne $BROKENKEY | xxd -p -c32) keyctl add user masterkey "$(cat masterkey.bin)" @u keyctl add encrypted testkey "new user:masterkey 32 $NEWKEY" @u However, NEWKEY is still broken: If for BROKENKEY 32 bytes were specified, a brute force attacker knowing the key properties would only need to try at most 2^(16*8) keys, as if the key was only 16 bytes long. The security issue is a result of the combination of limiting the input range to hex-ascii and using memcpy() instead of hex2bin(). It could have been fixed either by allowing binary input or using hex2bin() (and doubling the ascii input key length). This patch implements the latter. The corresponding test for the Linux Test Project ltp has also been fixed (see link below). Fixes: cd3bc044af48 ("KEYS: encrypted: Instantiate key with user-provided decrypted data") Cc: stable@kernel.org Link: https://lore.kernel.org/ltp/20221006081709.92303897@mail.steuer-voss.de/ Reviewed-by: Mimi Zohar Signed-off-by: Nikolaus Voss Signed-off-by: Mimi Zohar

KEYS: encrypted: Instantiate key with user-provided decrypted data

2022-02-22T00:47:45+00:00

For availability and performance reasons master keys often need to be released outside of a Key Management Service (KMS) to clients. It would be beneficial to provide a mechanism where the wrapping/unwrapping of data encryption keys (DEKs) is not dependent on a remote call at runtime yet security is not (or only minimally) compromised. Master keys could be securely stored in the Kernel and be used to wrap/unwrap keys from Userspace. The encrypted.c class supports instantiation of encrypted keys with either an already-encrypted key material, or by generating new key material based on random numbers. This patch defines a new datablob format: [] that allows to inject and encrypt user-provided decrypted data. The decrypted data must be hex-ascii encoded. Signed-off-by: Yael Tzur Reviewed-by: Mimi Zohar Reviewed-by: Sumit Garg Reviewed-by: Jarkko Sakkinen Signed-off-by: Mimi Zohar

crypto: sha - split sha.h into sha1.h and sha2.h

2020-11-20T03:45:33+00:00

Currently contains declarations for both SHA-1 and SHA-2, and contains declarations for SHA-3. This organization is inconsistent, but more importantly SHA-1 is no longer considered to be cryptographically secure. So to the extent possible, SHA-1 shouldn't be grouped together with any of the other SHA versions, and usage of it should be phased out. Therefore, split into two headers and , and make everyone explicitly specify whether they want the declarations for SHA-1, SHA-2, or both. This avoids making the SHA-1 declarations visible to files that don't want anything to do with SHA-1. It also prepares for potentially moving sha1.h into a new insecure/ or dangerous/ directory. Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Jason A. Donenfeld Signed-off-by: Herbert Xu