History log of /linux/crypto/Kconfig (Results 1 – 25 of 2178)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 6a42ff33 05-Mar-2026 Linus Torvalds <torvalds@linux-foundation.org>

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

Pull crypto library fixes from Eric Biggers:

- Several test fixes:

- Fix flakiness in the inter

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

Pull crypto library fixes from Eric Biggers:

- Several test fixes:

- Fix flakiness in the interrupt context tests in certain VMs

- Make the lib/crypto/ KUnit tests depend on the corresponding
library options rather than selecting them. This follows the
standard KUnit convention, and it fixes an issue where enabling
CONFIG_KUNIT_ALL_TESTS pulled in all the crypto library code

- Add a kunitconfig file for lib/crypto/

- Fix a couple stale references to "aes-generic" that made it in
concurrently with the rename to "aes-lib"

- Update the help text for several CRYPTO kconfig options to remove
outdated information about users that now use the library instead

* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux:
crypto: testmgr - Fix stale references to aes-generic
crypto: Clean up help text for CRYPTO_CRC32
crypto: Clean up help text for CRYPTO_CRC32C
crypto: Clean up help text for CRYPTO_XXHASH
crypto: Clean up help text for CRYPTO_SHA256
crypto: Clean up help text for CRYPTO_BLAKE2B
lib/crypto: tests: Add a .kunitconfig file
lib/crypto: tests: Depend on library options rather than selecting them
kunit: irq: Ensure timer doesn't fire too frequently

show more ...


Revision tags: v7.0-rc2
# f33ac74f 26-Feb-2026 Geert Uytterhoeven <geert+renesas@glider.be>

crypto: Clean up help text for CRYPTO_CRC32

F2fs and RoCEv2 stopped using this CRC32 implementation in commits
3ca4bec40ee211cd ("f2fs: switch to using the crc32 library") and
ccca5e8aa1457231 ("RDM

crypto: Clean up help text for CRYPTO_CRC32

F2fs and RoCEv2 stopped using this CRC32 implementation in commits
3ca4bec40ee211cd ("f2fs: switch to using the crc32 library") and
ccca5e8aa1457231 ("RDMA/rxe: switch to using the crc32 library").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/0f76ebf05bb1b6ca50db97988f9ac20944534b4c.1772116160.git.geert+renesas@glider.be
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# 0ef6eb10 26-Feb-2026 Geert Uytterhoeven <geert+renesas@glider.be>

crypto: Clean up help text for CRYPTO_CRC32C

Ext4, jbd2, iSCSI, NVMeoF/TCP, and Btrfs stopped using this CRC32c
implementation in commits f2b4fa19647e18a2 ("ext4: switch to using the
crc32c library"

crypto: Clean up help text for CRYPTO_CRC32C

Ext4, jbd2, iSCSI, NVMeoF/TCP, and Btrfs stopped using this CRC32c
implementation in commits f2b4fa19647e18a2 ("ext4: switch to using the
crc32c library"), dd348f054b24a3f5 ("jbd2: switch to using the crc32c
library"), 92186c1455a2d356 ("scsi: iscsi_tcp: Switch to using the
crc32c library"), 427fff9aff295e2c ("nvme-tcp: use crc32c() and
skb_copy_and_crc32c_datagram_iter()"), and fe11ac191ce0ad91 ("btrfs:
switch to library APIs for checksums").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/f567add7840bc612382237b3e76f3a8bdbd671e6.1772116160.git.geert+renesas@glider.be
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# a9ad29b7 26-Feb-2026 Geert Uytterhoeven <geert+renesas@glider.be>

crypto: Clean up help text for CRYPTO_XXHASH

Btrfs stopped using this xxHash implementation in commit
fe11ac191ce0ad91 ("btrfs: switch to library APIs for checksums").

Signed-off-by: Geert Uytterho

crypto: Clean up help text for CRYPTO_XXHASH

Btrfs stopped using this xxHash implementation in commit
fe11ac191ce0ad91 ("btrfs: switch to library APIs for checksums").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/3b632975201074ccaa129f4901a66aff87b19742.1772116160.git.geert+renesas@glider.be
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# a70d9d65 26-Feb-2026 Geert Uytterhoeven <geert+renesas@glider.be>

crypto: Clean up help text for CRYPTO_SHA256

NFS, Ceph, SMB, and Btrfs stopped using this SHA-256 implementation in
commits c2c90a8b2620626c ("nfsd: use SHA-256 library API instead of
crypto_shash A

crypto: Clean up help text for CRYPTO_SHA256

NFS, Ceph, SMB, and Btrfs stopped using this SHA-256 implementation in
commits c2c90a8b2620626c ("nfsd: use SHA-256 library API instead of
crypto_shash API"), 27c0a7b05d13a0dc ("libceph: Use HMAC-SHA256 library
instead of crypto_shash"), 924067ef183bd17f ("ksmbd: Use HMAC-SHA256
library for message signing and key generation"), and fe11ac191ce0ad91
("btrfs: switch to library APIs for checksums").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/bf8e1c229b36fc5349e29701e962d0dfd4fd21b6.1772116160.git.geert+renesas@glider.be
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# 5d75c7bc 26-Feb-2026 Geert Uytterhoeven <geert+renesas@glider.be>

crypto: Clean up help text for CRYPTO_BLAKE2B

Btrfs stopped using this BLAKE2b implementation in commit
fe11ac191ce0ad91 ("btrfs: switch to library APIs for checksums").

Signed-off-by: Geert Uytter

crypto: Clean up help text for CRYPTO_BLAKE2B

Btrfs stopped using this BLAKE2b implementation in commit
fe11ac191ce0ad91 ("btrfs: switch to library APIs for checksums").

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/98b983d2f2bddf0e5e8e1c970446c3c64527ef89.1772116160.git.geert+renesas@glider.be
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# c17ee635 23-Feb-2026 Maxime Ripard <mripard@kernel.org>

Merge drm/drm-fixes into drm-misc-fixes

7.0-rc1 was just released, let's merge it to kick the new release cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


Revision tags: v7.0-rc1
# b63c9072 10-Feb-2026 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'keys-next-20260206' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

Pull keys update from David Howells:
"This adds support for ML-DSA signatures in X.509 certificates

Merge tag 'keys-next-20260206' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

Pull keys update from David Howells:
"This adds support for ML-DSA signatures in X.509 certificates and
PKCS#7/CMS messages, thereby allowing this algorithm to be used for
signing modules, kexec'able binaries, wifi regulatory data, etc..

This requires OpenSSL-3.5 at a minimum and preferably OpenSSL-4 (so
that it can avoid the use of CMS signedAttrs - but that version is not
cut yet). certs/Kconfig does a check to hide the signing options if
OpenSSL does not list the algorithm as being available"

* tag 'keys-next-20260206' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
pkcs7: Change a pr_warn() to pr_warn_once()
pkcs7: Allow authenticatedAttributes for ML-DSA
modsign: Enable ML-DSA module signing
pkcs7, x509: Add ML-DSA support
pkcs7: Allow the signing algo to do whatever digestion it wants itself
pkcs7, x509: Rename ->digest to ->m
x509: Separately calculate sha256 for blacklist
crypto: Add ML-DSA crypto_sig support

show more ...


# 13d83ea9 10-Feb-2026 Linus Torvalds <torvalds@linux-foundation.org>

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

Pull crypto library updates from Eric Biggers:

- Add support for verifying ML-DSA signatures.

ML

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

Pull crypto library updates from Eric Biggers:

- Add support for verifying ML-DSA signatures.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a
recently-standardized post-quantum (quantum-resistant) signature
algorithm. It was known as Dilithium pre-standardization.

The first use case in the kernel will be module signing. But there
are also other users of RSA and ECDSA signatures in the kernel that
might want to upgrade to ML-DSA eventually.

- Improve the AES library:

- Make the AES key expansion and single block encryption and
decryption functions use the architecture-optimized AES code.
Enable these optimizations by default.

- Support preparing an AES key for encryption-only, using about
half as much memory as a bidirectional key.

- Replace the existing two generic implementations of AES with a
single one.

- Simplify how Adiantum message hashing is implemented. Remove the
"nhpoly1305" crypto_shash in favor of direct lib/crypto/ support for
NH hashing, and enable optimizations by default.

* tag 'libcrypto-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (53 commits)
lib/crypto: mldsa: Clarify the documentation for mldsa_verify() slightly
lib/crypto: aes: Drop 'volatile' from aes_sbox and aes_inv_sbox
lib/crypto: aes: Remove old AES en/decryption functions
lib/crypto: aesgcm: Use new AES library API
lib/crypto: aescfb: Use new AES library API
crypto: omap - Use new AES library API
crypto: inside-secure - Use new AES library API
crypto: drbg - Use new AES library API
crypto: crypto4xx - Use new AES library API
crypto: chelsio - Use new AES library API
crypto: ccp - Use new AES library API
crypto: x86/aes-gcm - Use new AES library API
crypto: arm64/ghash - Use new AES library API
crypto: arm/ghash - Use new AES library API
staging: rtl8723bs: core: Use new AES library API
net: phy: mscc: macsec: Use new AES library API
chelsio: Use new AES library API
Bluetooth: SMP: Use new AES library API
crypto: x86/aes - Remove the superseded AES-NI crypto_cipher
lib/crypto: x86/aes: Add AES-NI optimization
...

show more ...


Revision tags: v6.19, v6.19-rc8, v6.19-rc7, v6.19-rc6, v6.19-rc5, v6.19-rc4, v6.19-rc3, v6.19-rc2, v6.19-rc1, v6.18, v6.18-rc7
# d3b6dd90 20-Nov-2025 David Howells <dhowells@redhat.com>

crypto: Add ML-DSA crypto_sig support

Add verify-only public key crypto support for ML-DSA so that the
X.509/PKCS#7 signature verification code, as used by module signing,
amongst other things, can

crypto: Add ML-DSA crypto_sig support

Add verify-only public key crypto support for ML-DSA so that the
X.509/PKCS#7 signature verification code, as used by module signing,
amongst other things, can make use of it through the common crypto_sig API.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Lukas Wunner <lukas@wunner.de>
cc: Ignat Korchagin <ignat@cloudflare.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org

show more ...


# cc4adab1 20-Jan-2026 Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

Merge tag 'v6.19-rc1' into msm-next

Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC
config database defining UBWC_6).

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.q

Merge tag 'v6.19-rc1' into msm-next

Merge Linux 6.19-rc1 in order to catch up with other changes (e.g. UBWC
config database defining UBWC_6).

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

show more ...


# 641e7056 12-Jan-2026 Eric Biggers <ebiggers@kernel.org>

crypto: aes - Remove aes-fixed-time / CONFIG_CRYPTO_AES_TI

Remove aes-fixed-time, i.e. CONFIG_CRYPTO_AES_TI. This was a wrapper
around the 256-byte-table-based AES implementation in lib/crypto/aes.

crypto: aes - Remove aes-fixed-time / CONFIG_CRYPTO_AES_TI

Remove aes-fixed-time, i.e. CONFIG_CRYPTO_AES_TI. This was a wrapper
around the 256-byte-table-based AES implementation in lib/crypto/aes.c,
with extra code to enable and disable IRQs for constant-time hardening.

While nice in theory, in practice this had the following issues:

- For bulk en/decryption it was 2-4 times slower than aes-generic. This
resulted in aes-generic still being needed, creating fragmentation.

- Having both aes-generic and aes-fixed-time punted an AES
implementation decision to distros and users who are generally
unprepared to handle it. In practice, whether aes-fixed-time gets
used tends to be incidental and not match an explicit distro or user
intent. (While aes-fixed-time has a higher priority than aes-generic,
whether it actually gets enabled, loaded, and used depends on the
kconfig and whether a modprobe of "aes" happens to be done. It also
has a lower priority than aes-arm and aes-arm64.)

- My changes to the generic AES code (in other commits) significantly
close the gap with aes-fixed-time anyway. The table size is reduced
from 8192 bytes to 1024 bytes, and prefetching is added.

- While AES code *should* be constant-time, the real solutions for that
are AES instructions (which most CPUs have now) or bit-slicing. arm
and arm64 already have bit-sliced AES code for many modes; generic
bit-sliced code could be written but would be very slow for single
blocks. Overall, I suggest that trying to write constant-time
table-based AES code is a bit futile anyway, and in the rare cases
where a proper AES implementation is still unavailable it's reasonable
to compromise with an implementation that simply prefetches the table.

Thus, this commit removes aes-fixed-time and CONFIG_CRYPTO_AES_TI. The
replacement is just the existing CONFIG_CRYPTO_AES, which for now maps
to the existing aes-generic code, but I'll soon be changing to use the
improved AES library code instead.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-9-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# 637e73ef 12-Jan-2026 Eric Biggers <ebiggers@kernel.org>

crypto: aegis - Switch from crypto_ft_tab[] to aes_enc_tab[]

Instead of crypto_ft_tab[0] from aes_generic.c, use aes_enc_tab from
lib/crypto/aes.c. These contain the same data, so the result is the

crypto: aegis - Switch from crypto_ft_tab[] to aes_enc_tab[]

Instead of crypto_ft_tab[0] from aes_generic.c, use aes_enc_tab from
lib/crypto/aes.c. These contain the same data, so the result is the
same. This will allow aes_generic.c to eventually be removed.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20260112192035.10427-8-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# f676740c 11-Dec-2025 Eric Biggers <ebiggers@kernel.org>

crypto: nhpoly1305 - Remove crypto_shash support

Remove nhpoly1305 support from crypto_shash. It no longer has any user
now that crypto/adiantum.c no longer uses it.

Acked-by: Herbert Xu <herbert@

crypto: nhpoly1305 - Remove crypto_shash support

Remove nhpoly1305 support from crypto_shash. It no longer has any user
now that crypto/adiantum.c no longer uses it.

Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Link: https://lore.kernel.org/r/20251211011846.8179-11-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# 76987479 11-Dec-2025 Eric Biggers <ebiggers@kernel.org>

crypto: adiantum - Convert to use NH library

Reimplement the Adiantum message hashing using the nh() library
function, combined with some code which directly handles the Poly1305
stage. The latter

crypto: adiantum - Convert to use NH library

Reimplement the Adiantum message hashing using the nh() library
function, combined with some code which directly handles the Poly1305
stage. The latter code is derived from crypto/nhpoly1305.c.

This eliminates the dependency on the "nhpoly1305" crypto_shash
algorithm, which existed only to fit Adiantum message hashing into the
traditional Linux crypto API paradigm. Now that simple,
architecture-optimized library functions are a well-established option
too, we can switch to this simpler implementation.

Note: I've dropped the support for the optional third parameter of the
adiantum template, which specified the nhpoly1305 implementation. We
could keep accepting some strings in this parameter for backwards
compatibility, but I don't think it's being used. I believe only
"adiantum(xchacha12,aes)" and "adiantum(xchacha20,aes)" are used.

Link: https://lore.kernel.org/r/20251211011846.8179-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

show more ...


# 5add3c3c 19-Dec-2025 Thomas Hellström <thomas.hellstrom@linux.intel.com>

Merge drm/drm-next into drm-xe-next

Backmerging to bring in 6.19-rc1. An important upstream bugfix and
to help unblock PTL CI.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


# b8304863 15-Dec-2025 Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next

Sync-up some display code needed for Async flips refactor.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>


# 7f790dd2 15-Dec-2025 Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-misc-next

Let's kickstart the v6.20 (7.0?) release cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


# a4a508df 13-Dec-2025 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v6.18' into next

Sync up with the mainline to bring in the latest APIs.


# 24f171c7 21-Dec-2025 Takashi Iwai <tiwai@suse.de>

Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.19

We've been quite busy with fixes since the merge window, though

Merge tag 'asoc-fix-v6.19-rc1' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v6.19

We've been quite busy with fixes since the merge window, though not in
any particularly exciting ways - the standout thing is the fix for _SX
controls which were broken by a change to how we do clamping, otherwise
it's all fairly run of the mill fixes and quirks.

show more ...


# 84318277 15-Dec-2025 Maarten Lankhorst <dev@lankhorst.se>

Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Pull in rc1 to include all changes since the merge window closed,
and grab all fixes and changes from drm/drm-next.

Signed-off-by: M

Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Pull in rc1 to include all changes since the merge window closed,
and grab all fixes and changes from drm/drm-next.

Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>

show more ...


Revision tags: v6.18-rc6, v6.18-rc5, v6.18-rc4
# cb9f145f 01-Nov-2025 Rob Clark <robin.clark@oss.qualcomm.com>

Merge remote-tracking branch 'drm/drm-next' into msm-next-robclark

Back-merge drm-next to get caught up.

Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>


Revision tags: v6.18-rc3, v6.18-rc2
# 82ee5025 14-Oct-2025 Thomas Hellström <thomas.hellstrom@linux.intel.com>

Merge drm/drm-next into drm-xe-next

Backmerging to bring in 6.18-rc1.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


# 2acee98f 14-Oct-2025 Jani Nikula <jani.nikula@intel.com>

Merge drm/drm-next into drm-intel-next

Sync to v6.18-rc1.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>


# 9b966ae4 13-Oct-2025 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-next into drm-misc-next

Updating drm-misc-next to the state of v6.18-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


12345678910>>...88