Changes in Kconfig

3241cd0c - crypto,fs: Separate out hkdf_extract() and hkdf_expand()

Mon, 24 Feb 2025 12:38:09 +0000

crypto,fs: Separate out hkdf_extract() and hkdf_expand()Separate out the HKDF functions into a separate module toto make them available to other callers.And add a testsuite to the module with test vectorsfrom RFC 5869 (and additional vectors for SHA384 and SHA512)to ensure the integrity of the algorithm.Signed-off-by: Hannes Reinecke Acked-by: Eric Biggers Acked-by: Herbert Xu Signed-off-by: Keith Busch List of files: /linux-6.15/fs/crypto/Kconfig

75eb8b94 - Revert "fscrypt: relax Kconfig dependencies for crypto API algorithms"

Mon, 17 Feb 2025 18:53:14 +0000

Revert "fscrypt: relax Kconfig dependencies for crypto API algorithms"This mostly reverts commit a0fc20333ee4bac1147c4cf75dea098c26671a2f.Keep the relevant parts of the comment added by that commit.The problem with that commit is that it allowed people to create brokenconfigurations that enabled FS_ENCRYPTION but not the mandatoryalgorithms. An example of this can be found here:https://lore.kernel.org/r/1207325.1737387826@warthog.procyon.org.uk/The commit did allow people to disable specific generic algorithmimplementations that aren't needed. But that at best allowed saving abit of code. In the real world people are unlikely to intentionally andcorrectly make such a tweak anyway, as they tend to just be confused bywhat all the different crypto kconfig options mean.Of course we really need the crypto API to enable the correctimplementations automatically, but that's for a later fix.Acked-by: Ard Biesheuvel Cc: David Howells Cc: Herbert Xu Link: https://lore.kernel.org/r/20250217185314.27345-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

c1f1f5bf - fscrypt: document that CephFS supports fscrypt now

Wed, 27 Dec 2023 04:51:58 +0000

fscrypt: document that CephFS supports fscrypt nowThe help text for CONFIG_FS_ENCRYPTION and the fscrypt.rst documentationfile both list the filesystems that support fscrypt. CephFS addedsupport for fscrypt in v6.6, so add CephFS to the list.Link: https://lore.kernel.org/r/20231227045158.87276-1-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

a0fc2033 - fscrypt: relax Kconfig dependencies for crypto API algorithms

Wed, 21 Apr 2021 07:55:10 +0000

fscrypt: relax Kconfig dependencies for crypto API algorithmsEven if FS encryption has strict functional dependencies on variouscrypto algorithms and chaining modes. those dependencies could potentiallybe satisified by other implementations than the generic ones, and no linktime dependency exists on the 'depends on' claused defined byCONFIG_FS_ENCRYPTION_ALGS.So let's relax these clauses to 'imply', so that the default behavioris still to pull in those generic algorithms, but in a way that permitsthem to be disabled again in Kconfig.Signed-off-by: Ard Biesheuvel Acked-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/fs/crypto/Kconfig

bd0d97b7 - fscrypt: switch fscrypt_do_sha256() to use the SHA-256 library

Tue, 21 Jul 2020 22:59:16 +0000

fscrypt: switch fscrypt_do_sha256() to use the SHA-256 libraryfscrypt_do_sha256() is only used for hashing encrypted filenames tocreate no-key tokens, which isn't performance-critical. Therefore a Cimplementation of SHA-256 is sufficient.Also, the logic to create no-key tokens is always potentially needed.This differs from fscrypt's other dependencies on crypto API algorithms,which are conditionally needed depending on what encryption policiesuserspace is using. Therefore, for fscrypt there isn't much benefit toallowing SHA-256 to be a loadable module.So, make fscrypt_do_sha256() use the SHA-256 library instead of thecrypto_shash API. This is much simpler, since it avoids having toimplement one-time-init (which is hard to do correctly, and in fact wasimplemented incorrectly) and handle failures to allocate thecrypto_shash object.Fixes: edc440e3d27f ("fscrypt: improve format of no-key names")Cc: Daniel Rosenberg Link: https://lore.kernel.org/r/20200721225920.114347-2-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

5fee3609 - fscrypt: add inline encryption support

Thu, 02 Jul 2020 01:56:05 +0000

fscrypt: add inline encryption supportAdd support for inline encryption to fs/crypto/. With "inlineencryption", the block layer handles the decryption/encryption as partof the bio, instead of the filesystem doing the crypto itself viaLinux's crypto API. This model is needed in order to take advantage ofthe inline encryption hardware present on most modern mobile SoCs.To use inline encryption, the filesystem needs to be mounted with'-o inlinecrypt'. Blk-crypto will then be used instead of the traditionalfilesystem-layer crypto whenever possible to encrypt the contentsof any encrypted files in that filesystem. Fscrypt still provides the keyand IV to use, and the actual ciphertext on-disk is still the same;therefore it's testable using the existing fscrypt ciphertext verificationtests.Note that since blk-crypto has a fallback to Linux's crypto API, andalso supports all the encryption modes currently supported by fscrypt,this feature is usable and testable even without actual inlineencryption hardware.Per-filesystem changes will be needed to set encryption contexts whensubmitting bios and to implement the 'inlinecrypt' mount option. Thispatch just adds the common code.Signed-off-by: Satya Tangirala Reviewed-by: Jaegeuk Kim Reviewed-by: Eric Biggers Reviewed-by: Theodore Ts'o Link: https://lore.kernel.org/r/20200702015607.1215430-3-satyat@google.comCo-developed-by: Eric Biggers Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

edc440e3 - fscrypt: improve format of no-key names

Mon, 20 Jan 2020 22:32:01 +0000

fscrypt: improve format of no-key namesWhen an encrypted directory is listed without the key, the filesystemmust show "no-key names" that uniquely identify directory entries, areat most 255 (NAME_MAX) bytes long, and don't contain '/' or '\0'.Currently, for short names the no-key name is the base64 encoding of theciphertext filename, while for long names it's the base64 encoding ofthe ciphertext filename's dirhash and second-to-last 16-byte block.This format has the following problems:- Since it doesn't always include the dirhash, it's incompatible with directories that will use a secret-keyed dirhash over the plaintext filenames. In this case, the dirhash won't be computable from the ciphertext name without the key, so it instead must be retrieved from the directory entry and always included in the no-key name. Casefolded encrypted directories will use this type of dirhash.- It's ambiguous: it's possible to craft two filenames that map to the same no-key name, since the method used to abbreviate long filenames doesn't use a proper cryptographic hash function.Solve both these problems by switching to a new no-key name format thatis the base64 encoding of a variable-length structure that contains thedirhash, up to 149 bytes of the ciphertext filename, and (if any bytesremain) the SHA-256 of the remaining bytes of the ciphertext filename.This ensures that each no-key name contains everything needed to findthe directory entry again, contains only legal characters, doesn'texceed NAME_MAX, is unambiguous unless there's a SHA-256 collision, andthat we only take the performance hit of SHA-256 on very long filenames.Note: this change does *not* address the existing issue where users canmodify the 'dirhash' part of a no-key name and the filesystem may stillaccept the name.Signed-off-by: Daniel Rosenberg [EB: improved comments and commit message, fixed checking return value of base64_decode(), check for SHA-256 error, continue to set disk_name for short names to keep matching simpler, and many other cleanups]Link: https://lore.kernel.org/r/20200120223201.241390-7-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

ede7a09f - fscrypt: Allow modular crypto algorithms

Fri, 27 Dec 2019 02:47:00 +0000

fscrypt: Allow modular crypto algorithmsThe commit 643fa9612bf1 ("fscrypt: remove filesystem specificbuild config option") removed modular support for fs/crypto. Thiscauses the Crypto API to be built-in whenever fscrypt is enabled.This makes it very difficult for me to test modular builds ofthe Crypto API without disabling fscrypt which is a pain.As fscrypt is still evolving and it's developing new ties with thefs layer, it's hard to build it as a module for now.However, the actual algorithms are not required until a filesystemis mounted. Therefore we can allow them to be built as modules.Signed-off-by: Herbert Xu Link: https://lore.kernel.org/r/20191227024700.7vrzuux32uyfdgum@gondor.apana.org.auSigned-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

c1144c9b - fscrypt: add an HKDF-SHA512 implementation

Mon, 05 Aug 2019 02:35:47 +0000

fscrypt: add an HKDF-SHA512 implementationAdd an implementation of HKDF (RFC 5869) to fscrypt, for the purpose ofderiving additional key material from the fscrypt master keys for v2encryption policies. HKDF is a key derivation function built on top ofHMAC. We choose SHA-512 for the underlying unkeyed hash, and use an"hmac(sha512)" transform allocated from the crypto API.We'll be using this to replace the AES-ECB based KDF currently used toderive the per-file encryption keys. While the AES-ECB based KDF isbelieved to meet the original security requirements, it is nonstandardand has problems that don't exist in modern KDFs such as HKDF:1. It's reversible. Given a derived key and nonce, an attacker can easily compute the master key. This is okay if the master key and derived keys are equally hard to compromise, but now we'd like to be more robust against threats such as a derived key being compromised through a timing attack, or a derived key for an in-use file being compromised after the master key has already been removed.2. It doesn't evenly distribute the entropy from the master key; each 16 input bytes only affects the corresponding 16 output bytes.3. It isn't easily extensible to deriving other values or keys, such as a public hash for securely identifying the key, or per-mode keys. Per-mode keys will be immediately useful for Adiantum encryption, for which fscrypt currently uses the master key directly, introducing unnecessary usage constraints. Per-mode keys will also be useful for hardware inline encryption, which is currently being worked on.HKDF solves all the above problems.Reviewed-by: Paul Crowley Reviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

adbd9b4d - fscrypt: remove selection of CONFIG_CRYPTO_SHA256

Thu, 20 Jun 2019 18:15:05 +0000

fscrypt: remove selection of CONFIG_CRYPTO_SHA256fscrypt only uses SHA-256 for AES-128-CBC-ESSIV, which isn't the defaultand is only recommended on platforms that have hardware acceleratedAES-CBC but not AES-XTS. There's no link-time dependency, since SHA-256is requested via the crypto API on first use.To reduce bloat, we should limit FS_ENCRYPTION to selecting the defaultalgorithms only. SHA-256 by itself isn't that much bloat, but it'sbeing discussed to move ESSIV into a crypto API template, which wouldincidentally bring in other things like "authenc" support, which wouldall end up being built-in since FS_ENCRYPTION is now a bool.For Adiantum encryption we already just document that users who want touse it have to enable CONFIG_CRYPTO_ADIANTUM themselves. So, let's dothe same for AES-128-CBC-ESSIV and CONFIG_CRYPTO_SHA256.Acked-by: Ard Biesheuvel Reviewed-by: Theodore Ts'o Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

ec8f24b7 - treewide: Add SPDX license identifier - Makefile/Kconfig

Sun, 19 May 2019 12:07:45 +0000

treewide: Add SPDX license identifier - Makefile/KconfigAdd SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any formThese files fall under the project license, GPL v2 only. The resulting SPDXlicense identifier is: GPL-2.0-onlySigned-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/fs/crypto/Kconfig

643fa961 - fscrypt: remove filesystem specific build config option

Wed, 12 Dec 2018 09:50:12 +0000

fscrypt: remove filesystem specific build config optionIn order to have a common code base for fscrypt "post read" processingfor all filesystems which support encryption, this commit removesfilesystem specific build config option (e.g. CONFIG_EXT4_FS_ENCRYPTION)and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whosevalue affects all the filesystems making use of fscrypt.Reviewed-by: Eric Biggers Signed-off-by: Chandan Rajendra Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

1058ef0d - fscrypt: remove CRYPTO_CTR dependency

Wed, 05 Sep 2018 19:24:00 +0000

fscrypt: remove CRYPTO_CTR dependencyfscrypt doesn't use the CTR mode of operation for anything, so there'sno need to select CRYPTO_CTR. It was added by commit 71dea01ea2ed("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4 encryption isenabled"). But, I've been unable to identify the arm64 crypto bug itwas supposedly working around.I suspect the issue was seen only on some old Android device kernel(circa 3.10?). So if the fix wasn't mistaken, the real bug is probablyalready fixed. Or maybe it was actually a bug in a non-upstream cryptodriver.So, remove the dependency. If it turns out there's actually still abug, we'll fix it properly.Signed-off-by: Eric Biggers List of files: /linux-6.15/fs/crypto/Kconfig

b7e7cf7a - fscrypt: add support for AES-128-CBC

Mon, 19 Jun 2017 07:27:58 +0000

fscrypt: add support for AES-128-CBCfscrypt provides facilities to use different encryption algorithms whichare selectable by userspace when setting the encryption policy. Currently,only AES-256-XTS for file contents and AES-256-CBC-CTS for file names areimplemented. This is a clear case of kernel offers the mechanism anduserspace selects a policy. Similar to what dm-crypt and ecryptfs have.This patch adds support for using AES-128-CBC for file contents andAES-128-CBC-CTS for file name encryption. To mitigate watermarkingattacks, IVs are generated using the ESSIV algorithm. While AES-CBC isactually slightly less secure than AES-XTS from a security point of view,there is more widespread hardware support. Using AES-CBC gives us theacceptable performance while still providing a moderate level of securityfor persistent storage.Especially low-powered embedded devices with crypto accelerators such asCAAM or CESA often only support AES-CBC. Since using AES-CBC over AES-XTSis basically thought of a last resort, we use AES-128-CBC over AES-256-CBCsince it has less encryption rounds and yields noticeable betterperformance starting from a file size of just a few kB.Signed-off-by: Daniel Walter [david@sigma-star.at: addressed review comments]Signed-off-by: David Gstir Reviewed-by: Eric Biggers Signed-off-by: Theodore Ts'o List of files: /linux-6.15/fs/crypto/Kconfig

58ae7468 - fscrypt: factor out bio specific functions

Mon, 19 Dec 2016 11:25:32 +0000

fscrypt: factor out bio specific functionsThat way we can get rid of the direct dependency on CONFIG_BLOCK.Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")Reported-by: Arnd Bergmann Reported-by: Randy Dunlap Reviewed-by: Eric Biggers Reviewed-by: Christoph Hellwig Reviewed-by: David Gstir Signed-off-by: Richard Weinberger Signed-off-by: Theodore Ts'o List of files: /linux-6.15/fs/crypto/Kconfig

80481235 - fscrypto: remove unneeded Kconfig dependencies

Sat, 26 Nov 2016 20:06:43 +0000

fscrypto: remove unneeded Kconfig dependenciesSHA256 and ENCRYPTED_KEYS are not needed. CTR shouldn't be neededeither, but I left it for now because it was intentionally added bycommit 71dea01ea2ed ("ext4 crypto: require CONFIG_CRYPTO_CTR if ext4encryption is enabled"). So it sounds like there may be a dependencyproblem elsewhere, which I have not been able to identify specifically,that must be solved before CTR can be removed.Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o List of files: /linux-6.15/fs/crypto/Kconfig

0b81d077 - fs crypto: move per-file encryption from f2fs tree to fs/crypto

Fri, 15 May 2015 23:26:10 +0000

fs crypto: move per-file encryption from f2fs tree to fs/cryptoThis patch adds the renamed functions moved from the f2fs crypto files.1. definitions for per-file encryption used by ext4 and f2fs.2. crypto.c for encrypt/decrypt functions a. IO preparation: - fscrypt_get_ctx / fscrypt_release_ctx b. before IOs: - fscrypt_encrypt_page - fscrypt_decrypt_page - fscrypt_zeroout_range c. after IOs: - fscrypt_decrypt_bio_pages - fscrypt_pullback_bio_page - fscrypt_restore_control_page3. policy.c supporting context management. a. For ioctls: - fscrypt_process_policy - fscrypt_get_policy b. For context permission - fscrypt_has_permitted_context - fscrypt_inherit_context4. keyinfo.c to handle permissions - fscrypt_get_encryption_info - fscrypt_free_encryption_info5. fname.c to support filename encryption a. general wrapper functions - fscrypt_fname_disk_to_usr - fscrypt_fname_usr_to_disk - fscrypt_setup_filename - fscrypt_free_filename b. specific filename handling functions - fscrypt_fname_alloc_buffer - fscrypt_fname_free_buffer6. Makefile and KconfigCc: Al Viro Signed-off-by: Michael Halcrow Signed-off-by: Ildar Muslukhov Signed-off-by: Uday Savagaonkar Signed-off-by: Theodore Ts'o Signed-off-by: Arnd Bergmann Signed-off-by: Jaegeuk Kim List of files: /linux-6.15/fs/crypto/Kconfig