#
# Cryptographic API Configuration
#
menuconfig CRYPTO
tristate "Cryptographic API"
select CRYPTO_LIB_UTILS help
This option provides the core Cryptographic API.
if CRYPTO
menu "Crypto core or helper"
config CRYPTO_FIPS
bool "FIPS 200 compliance"
depends on (CRYPTO_ANSI_CPRNG || CRYPTO_DRBG) && CRYPTO_SELFTESTS
depends on (MODULE_SIG || !MODULES) help
This option enables the fips boot option which is
required if you want the system to operate in a FIPS 200
certification. You should say no unless you know what
this is.
config CRYPTO_FIPS_NAME
string "FIPS Module Name"
default "Linux Kernel Cryptographic API"
depends on CRYPTO_FIPS help
This option sets the FIPS Module name reported by the Crypto API via
the /proc/sys/crypto/fips_name file.
config CRYPTO_FIPS_CUSTOM_VERSION
bool "Use Custom FIPS Module Version"
depends on CRYPTO_FIPS
default n
config CRYPTO_FIPS_VERSION
string "FIPS Module Version"
default "(none)"
depends on CRYPTO_FIPS_CUSTOM_VERSION help
This option provides the ability to override the FIPS Module Version. By default the KERNELRELEASE valueis used.
config CRYPTO_ALGAPI
tristate
select CRYPTO_ALGAPI2 help
This option provides the API for cryptographic algorithms.
config CRYPTO_HKDF
tristate
select CRYPTO_SHA256 if CRYPTO_SELFTESTS
select CRYPTO_SHA512 if CRYPTO_SELFTESTS
select CRYPTO_HASH2
config CRYPTO_MANAGER
tristate
default CRYPTO_ALGAPI if CRYPTO_SELFTESTS
select CRYPTO_MANAGER2 help
This provides the support for instantiating templates such as
cbc(aes), and the support for the crypto self-tests.
config CRYPTO_USER
tristate "Userspace cryptographic algorithm configuration"
depends on NET
select CRYPTO_MANAGER help
Userspace configuration for cryptographic instantiations such as
cbc(aes).
config CRYPTO_SELFTESTS
bool "Enable cryptographic self-tests"
depends on EXPERT help
Enable the cryptographic self-tests.
The cryptographic self-tests run at boot time, or at algorithm
registration time if algorithms are dynamically loaded later.
There are two main use cases for these tests:
- Development and pre-release testing. In this case, also enable
CRYPTO_SELFTESTS_FULL to get the full set of tests. All crypto code in the kernel is expected to pass the full set of tests.
- Production kernels, tohelp prevent buggy drivers from being used and/or meet FIPS 140-3 pre-operational testing requirements. In
this case, enable CRYPTO_SELFTESTS but not CRYPTO_SELFTESTS_FULL.
config CRYPTO_SELFTESTS_FULL
bool "Enable the full set of cryptographic self-tests"
depends on CRYPTO_SELFTESTS help
Enable the full set of cryptographic self-tests for each algorithm.
The full set of tests should be enabled for development and
pre-release testing, but not in production kernels.
All crypto code in the kernel is expected to pass the full tests.
config CRYPTO_NULL
tristate "Null algorithms"
select CRYPTO_ALGAPI
select CRYPTO_SKCIPHER
select CRYPTO_HASH help
These are 'Null' algorithms, used by IPsec, which do nothing.
config CRYPTO_PCRYPT
tristate "Parallel crypto engine"
depends on SMP
select PADATA
select CRYPTO_MANAGER
select CRYPTO_AEAD help
This converts an arbitrary crypto algorithm into a parallel
algorithm that executes in kernel threads.
config CRYPTO_CRYPTD
tristate "Software async crypto daemon"
select CRYPTO_SKCIPHER
select CRYPTO_HASH
select CRYPTO_MANAGER help
This is a generic software asynchronous crypto daemon that
converts an arbitrary synchronous software crypto algorithm
into an asynchronous algorithm that executes in a kernel thread.
config CRYPTO_AUTHENC
tristate "Authenc support"
select CRYPTO_AEAD
select CRYPTO_SKCIPHER
select CRYPTO_MANAGER
select CRYPTO_HASH help
Authenc: Combined mode wrapper for IPsec.
This is required for IPSec ESP (XFRM_ESP).
config CRYPTO_KRB5ENC
tristate "Kerberos 5 combined hash+cipher support"
select CRYPTO_AEAD
select CRYPTO_SKCIPHER
select CRYPTO_MANAGER
select CRYPTO_HASH help
Combined hash and cipher support for Kerberos 5 RFC3961 simplified
profile. This is required for Kerberos 5-style encryption, used by
sunrpc/NFS and rxrpc/AFS.
config CRYPTO_BENCHMARK
tristate "Crypto benchmarking module"
depends on m || EXPERT
select CRYPTO_MANAGER help
Quick & dirty crypto benchmarking module.
This is mainly intended foruseby people developing cryptographic
algorithms in the kernel. It should not be enabled in production
kernels.
config CRYPTO_DH_RFC7919_GROUPS
bool "RFC 7919 FFDHE groups"
depends on CRYPTO_DH
select CRYPTO_RNG_DEFAULT help
FFDHE (Finite-Field-based Diffie-Hellman Ephemeral) groups
defined in RFC7919.
Support these finite-field groups in DH key exchanges:
- ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192
Rijndael appears to be consistently a very good performer in
both hardware and software across a wide range of computing
environments regardless of its usein feedback or non-feedback
modes. Its key setup time is excellent, and its key agility is
good. Rijndael's very low memory requirements make it very well
suited for restricted-space environments, in which it also
demonstrates excellent performance. Rijndael's operations are
among the easiest to defend against power and timing attacks.
The AES specifies three key sizes: 128, 192 and 256 bits
This is a generic implementation of AES that attempts to eliminate
data dependent latencies as much as possible without affecting
performance too much. It is intended foruseby the generic CCM and GCM drivers, and other CTR or CMAC/XCBC based modes that rely
solely on encryption (although decryption is supported as well, but with a more dramatic performance hit)
Instead of using 16 lookup tables of 1 KB each, (8 for encryption and
8 for decryption), this implementation only uses just two S-boxes of
256 bytes each, and attempts to eliminate data dependent latencies by
prefetching the entire table into the cache at the start of each
block. Interrupts are also disabled to avoid races where cachelines
are evicted when the CPU is interrupted to do something else.
config CRYPTO_ANUBIS
tristate "Anubis"
depends on CRYPTO_USER_API_ENABLE_OBSOLETE
select CRYPTO_ALGAPI help
Anubis cipher algorithm
Anubis is a variable key length cipher which can use keys from
128 bits to 320 bits in length. It was evaluated as a entrant in the NESSIE competition.
ARIA is a standard encryption algorithm of the Republic of Korea.
The ARIA specifies three key sizes and rounds.
128-bit: 12 rounds.
192-bit: 14 rounds.
256-bit: 16 rounds.
config CRYPTO_BLOWFISH
tristate "Blowfish"
select CRYPTO_ALGAPI
select CRYPTO_BLOWFISH_COMMON help
Blowfish cipher algorithm, by Bruce Schneier
This is a variable key length cipher which can use keys from 32
bits to 448 bits in length. It's fast, simple and specifically
designed foruse on "large microprocessors".
config CRYPTO_DES
tristate "DES and Triple DES EDE"
select CRYPTO_ALGAPI
select CRYPTO_LIB_DES help
DES (Data Encryption Standard)(FIPS 46-2, ISO/IEC 18033-3) and
Triple DES EDE (Encrypt/Decrypt/Encrypt) (FIPS 46-3, ISO/IEC 18033-3)
cipher algorithms
config CRYPTO_FCRYPT
tristate "FCrypt"
select CRYPTO_ALGAPI
select CRYPTO_SKCIPHER help
FCrypt algorithm used by RxRPC
config CRYPTO_KHAZAD
tristate "Khazad"
depends on CRYPTO_USER_API_ENABLE_OBSOLETE
select CRYPTO_ALGAPI help
Khazad cipher algorithm
Khazad was a finalist in the initial NESSIE competition. It is
an algorithm optimized for 64-bit processors with good performance
on 32-bit processors. Khazad uses an 128 bit key size.
config CRYPTO_SEED
tristate "SEED"
depends on CRYPTO_USER_API_ENABLE_OBSOLETE
select CRYPTO_ALGAPI help
SEED cipher algorithm (RFC4269, ISO/IEC 18033-3)
SEED is a 128-bit symmetric key block cipher that has been
developed by KISA (Korea Information Security Agency) as a
national standard encryption algorithm of the Republic of Korea.
It is a 16 round block cipher with the key size of 128 bit.
SM4 (GBT.32907-2016) is a cryptographic standard issued by the
Organization of State Commercial Administration of China (OSCCA)
as an authorized cryptographic algorithms for the use within China.
SMS4 was originally created forusein protecting wireless
networks, andis mandated in the Chinese National Standard for
Wireless LAN WAPI (Wired Authentication and Privacy Infrastructure)
(GB.15629.11-2003).
The latest SM4 standard (GBT.32907-2016) was proposed by OSCCA and
standardized through TC 260 of the Standardization Administration
of the People's Republic of China (SAC).
The input, output, and key of SMS4 are each 128 bits.
Twofish was submitted as an AES (Advanced Encryption Standard)
candidate cipher by researchers at CounterPane Systems. It is a
16 round block cipher supporting key sizes of 128, 192, and 256
bits.
Designed for fast and secure disk encryption, especially on
CPUs without dedicated crypto instructions. It encrypts
each sector using the XChaCha12 stream cipher, two passes of
an ε-almost-∆-universal hash function, and an invocation of
the AES-256 block cipher on a single 16-byte block. On CPUs
without AES instructions, Adiantum is much faster than
AES-XTS.
Adiantum's security is provably reducible to that of its
underlying stream and block ciphers, subject to a security
bound. Unlike XTS, Adiantum is a true wide-block encryption
mode, so it actually provides an even stronger notion of
security than XTS, subject to the security bound.
If unsure, say N.
config CRYPTO_ARC4
tristate "ARC4 (Alleged Rivest Cipher 4)"
depends on CRYPTO_USER_API_ENABLE_OBSOLETE
select CRYPTO_SKCIPHER
select CRYPTO_LIB_ARC4 help
ARC4 cipher algorithm
ARC4 is a stream cipher using keys ranging from 8 bits to 2048
bits in length. This algorithm is required for driver-based
WEP, but it should not be for other purposes because of the
weakness of the algorithm.
config CRYPTO_CHACHA20
tristate "ChaCha"
select CRYPTO_LIB_CHACHA
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_SKCIPHER help
The ChaCha20, XChaCha20, and XChaCha12 stream cipher algorithms
ChaCha20 is a 256-bit high-speed stream cipher designed by Daniel J.
Bernstein and further specified in RFC7539 forusein IETF protocols.
This is the portable C implementation of ChaCha20. See https://cr.yp.to/chacha/chacha-20080128.pdf for further information.
XChaCha20 is the application of the XSalsa20 construction to ChaCha20
rather than to Salsa20. XChaCha20 extends ChaCha20's nonce length from 64 bits (or 96 bits using the RFC7539 convention) to 192 bits,
while provably retaining ChaCha20's security. See https://cr.yp.to/snuffle/xsalsa-20081128.pdf for further information.
XChaCha12 is XChaCha20 reduced to 12 rounds, with correspondingly
reduced security margin but increased performance. It can be needed in some performance-sensitive scenarios.
config CRYPTO_CTS
tristate "CTS (Cipher Text Stealing)"
select CRYPTO_SKCIPHER
select CRYPTO_MANAGER help
CBC-CS3 variant of CTS (Cipher Text Stealing) (NIST
Addendum to SP800-38A (October 2010))
This mode is required for Kerberos gss mechanism support for AES encryption.
A mode for storage encryption that is efficient on processors with
instructions to accelerate AES and carryless multiplication, e.g.
x86 processors with AES-NI and CLMUL, and ARM processors with the
ARMv8 crypto extensions.
A tweakable, non malleable, non movable
narrow block cipher mode for dm-crypt. Use it with cipher specification string aes-lrw-benbi, the key must be 256, 320 or 384.
The first 128, 192 or 256 bits in the key are used for AES and the
rest is used to tie each cipher block to its logical position.
config CRYPTO_SEQIV
tristate "Sequence Number IV Generator"
select CRYPTO_GENIV help
Sequence Number IV generator
This IV generator generates an IV based on a sequence number by
xoring it with a salt. This algorithm is mainly useful for CTR.
This is required for IPsec ESP (XFRM_ESP).
config CRYPTO_ECHAINIV
tristate "Encrypted Chain IV Generator"
select CRYPTO_GENIV help
Encrypted Chain IV generator
This IV generator generates an IV based on the encryption of
a sequence number xored with a salt. This is the default
algorithm for CBC.
config CRYPTO_ESSIV
tristate "Encrypted Salt-Sector IV Generator"
select CRYPTO_AUTHENC help
Encrypted Salt-Sector IV generator
This IV generator is used in some cases by fscrypt and/or
dm-crypt. It uses the hash of the block encryption key as the
symmetric key for a block encryption pass applied to the input
IV, making low entropy IV sources more suitable for block
encryption.
This driver implements a crypto API template that can be
instantiated either as an skcipher or as an AEAD (depending on the
type of the first template argument), and which defers encryption and decryption requests to the encapsulated cipher after applying
ESSIV to the input IV. Note that in the AEAD case, it is assumed
that the keys are presented in the same format used by the authenc
template, and that the IV appears at the end of the authenticated
associated data (AAD) region (which is how dm-crypt uses it.)
Note that the use of ESSIV is not recommended for new deployments, and so this only needs to be enabled when interoperability with
existing encrypted volumes of filesystems is required, or when
building for a particular system that requires it (e.g., when
the SoC in question has accelerated CBC but not XTS, making CBC
combined with ESSIV the only feasible mode for h/w accelerated
block encryption)
endmenu
menu "Hashes, digests, and MACs"
config CRYPTO_BLAKE2B
tristate "BLAKE2b"
select CRYPTO_HASH help
BLAKE2b cryptographic hash function (RFC 7693)
BLAKE2b is optimized for 64-bit platforms and can produce digests
of any size between 1 and 64 bytes. The keyed hash isalso implemented.
This module provides the following algorithms:
- blake2b-160
- blake2b-256
- blake2b-384
- blake2b-512
This is used in HCTR2. It is not a general-purpose
cryptographic hash function.
config CRYPTO_RMD160
tristate "RIPEMD-160"
select CRYPTO_HASH help
RIPEMD-160 hash function (ISO/IEC 10118-3)
RIPEMD-160 is a 160-bit cryptographic hash function. It is intended to be used as a secure replacement for the 128-bit hash functions
MD4, MD5 and its predecessor RIPEMD
(not to be confused with RIPEMD-128).
Its speed is comparable to SHA-1 and there are no known attacks
against RIPEMD-160.
config CRYPTO_STREEBOG
tristate "Streebog"
select CRYPTO_HASH help
Streebog Hash Function (GOST R 34.11-2012, RFC 6986, ISO/IEC 10118-3)
This is one of the Russian cryptographic standard algorithms (called
GOST algorithms). This setting enables two hash algorithms with
256 and 512 bits output.
Extremely fast, working at speeds close to RAM limits.
Used by the btrfs filesystem.
endmenu
menu "CRCs (cyclic redundancy checks)"
config CRYPTO_CRC32C
tristate "CRC32c"
select CRYPTO_HASH
select CRC32 help
CRC32c CRC algorithm with the iSCSI polynomial (RFC 3385 and RFC 3720)
A 32-bit CRC (cyclic redundancy check) with a polynomial defined by G. Castagnoli, S. Braeuer and M. Herrman in"Optimization of Cyclic
Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transactions
on Communications, Vol. 41, No. 6, June 1993, selected forusewith
iSCSI.
config CRYPTO_ANSI_CPRNG
tristate "ANSI PRNG (Pseudo Random Number Generator)"
select CRYPTO_AES
select CRYPTO_RNG help
Pseudo RNG (random number generator) (ANSI X9.31 Appendix A.2.4)
This uses the AES cipher algorithm.
Note that this option must be enabled if CRYPTO_FIPS is selected
menuconfig CRYPTO_DRBG_MENU
tristate "NIST SP800-90A DRBG (Deterministic Random Bit Generator)" help
DRBG (Deterministic Random Bit Generator) (NIST SP800-90A)
In the following submenu, one or more of the DRBG types must be selected.
if CRYPTO_DRBG_MENU
config CRYPTO_DRBG_HMAC
bool
default y
select CRYPTO_HMAC
select CRYPTO_SHA512
config CRYPTO_DRBG_HASH
bool "Hash_DRBG"
select CRYPTO_SHA256 help
Hash_DRBG variant as defined in NIST SP800-90A.
This uses the SHA-1, SHA-256, SHA-384, or SHA-512 hash algorithms.
config CRYPTO_DRBG_CTR
bool "CTR_DRBG"
select CRYPTO_AES
select CRYPTO_CTR help
CTR_DRBG variant as defined in NIST SP800-90A.
This uses the AES cipher algorithm with the counter block mode.
config CRYPTO_JITTERENTROPY
tristate "CPU Jitter Non-Deterministic RNG (Random Number Generator)"
select CRYPTO_RNG
select CRYPTO_SHA3 help
CPU Jitter RNG (Random Number Generator) from the Jitterentropy library
A non-physical non-deterministic ("true") RNG (e.g., an entropy source
compliant with NIST SP800-90B) intended to provide a seed to a
deterministic RNG (e.g., per NIST SP800-90C).
This RNG does not perform any cryptographic whitening of the generated
random numbers.
choice
prompt "CPU Jitter RNG Memory Size"
default CRYPTO_JITTERENTROPY_MEMSIZE_2 help
The Jitter RNG measures the execution time of memory accesses.
Multiple consecutive memory accesses are performed. If the memory
size fits into a cache (e.g. L1), only the memory access timing to that cache is measured. The closer the cache isto the CPU
the less variations are measured andthus the less entropy is
obtained. Thus, if the memory size fits into the L1 cache, the
obtained entropy is less than if the memory size fits within
L1 + L2, which in turn is less if the memory fits into
L1 + L2 + L3. Thus, by selecting a different memory size,
the entropy rate produced by the Jitter RNG can be modified.
config CRYPTO_JITTERENTROPY_MEMORY_BLOCKS
int
default 64 if CRYPTO_JITTERENTROPY_MEMSIZE_2
default 512 if CRYPTO_JITTERENTROPY_MEMSIZE_128
default 1024 if CRYPTO_JITTERENTROPY_MEMSIZE_1024
default 4096 if CRYPTO_JITTERENTROPY_MEMSIZE_8192
config CRYPTO_JITTERENTROPY_MEMORY_BLOCKSIZE
int
default 32 if CRYPTO_JITTERENTROPY_MEMSIZE_2
default 256 if CRYPTO_JITTERENTROPY_MEMSIZE_128
default 1024 if CRYPTO_JITTERENTROPY_MEMSIZE_1024
default 2048 if CRYPTO_JITTERENTROPY_MEMSIZE_8192
config CRYPTO_JITTERENTROPY_OSR
int "CPU Jitter RNG Oversampling Rate"
range 1 15
default 3 help
The Jitter RNG allows the specification of an oversampling rate (OSR).
The Jitter RNG operation requires a fixed amount of timing
measurements to produce one output block of random numbers. The
OSR valueis multiplied with the amount of timing measurements to
generate one output block. Thus, the timing measurement is oversampled by the OSR factor. The oversampling allows the Jitter RNG to operate
on hardware whose timers deliver limited amount of entropy (e.g.
the timer is coarse) by setting the OSR to a higher value. The
trade-off, however, is that the Jitter RNG now requires more time to generate random numbers.
config CRYPTO_JITTERENTROPY_TESTINTERFACE
bool "CPU Jitter RNG Test Interface" help
The test interface allows a privileged process to capture
the raw unconditioned high resolution time stamp noise that is collected by the Jitter RNG for statistical analysis. As
this data is used at the same time to generate random bits,
the Jitter RNG operates in an insecure mode as long as the
recording is enabled. This interface therefore is only
intended for testing purposes andis not suitable for
production systems.
The raw noise data can be obtained using the jent_raw_hires
debugfs file. Using the option
jitterentropy_testing.boot_raw_hires_test=1 the raw noise of
the first 1000 entropy events since boot can be sampled.
If unsure, select N.
endif # if CRYPTO_FIPS && EXPERT
if !(CRYPTO_FIPS && EXPERT)
config CRYPTO_JITTERENTROPY_MEMORY_BLOCKS
int
default 64
config CRYPTO_JITTERENTROPY_MEMORY_BLOCKSIZE
int
default 32
config CRYPTO_JITTERENTROPY_OSR
int
default 1
config CRYPTO_JITTERENTROPY_TESTINTERFACE
bool
endif # if !(CRYPTO_FIPS && EXPERT)
endif # if CRYPTO_JITTERENTROPY
config CRYPTO_USER_API_HASH
tristate "Hash algorithms"
depends on NET
select CRYPTO_HASH
select CRYPTO_USER_API help
Enable the userspace interface for hash algorithms.
config CRYPTO_USER_API_SKCIPHER
tristate "Symmetric key cipher algorithms"
depends on NET
select CRYPTO_SKCIPHER
select CRYPTO_USER_API help
Enable the userspace interface for symmetric key cipher algorithms.
config CRYPTO_USER_API_RNG
tristate "RNG (random number generator) algorithms"
depends on NET
select CRYPTO_RNG
select CRYPTO_USER_API help
Enable the userspace interface for RNG (random number generator)
algorithms.
config CRYPTO_USER_API_RNG_CAVP
bool "Enable CAVP testing of DRBG"
depends on CRYPTO_USER_API_RNG && CRYPTO_DRBG help
Enable extra APIs in the userspace interface for NIST CAVP
(Cryptographic Algorithm Validation Program) testing:
- resetting DRBG entropy
- providing Additional Data
This should only be enabled for CAVP testing. You should say
no unless you know what this is.
config CRYPTO_USER_API_AEAD
tristate "AEAD cipher algorithms"
depends on NET
select CRYPTO_AEAD
select CRYPTO_SKCIPHER
select CRYPTO_USER_API help
Enable the userspace interface for AEAD cipher algorithms.
config CRYPTO_USER_API_ENABLE_OBSOLETE
bool "Obsolete cryptographic algorithms"
depends on CRYPTO_USER_API
default y help
Allow obsolete cryptographic algorithms to be selected that have
already been phased out from internal useby the kernel, and are
only useful for userspace clients that still rely on them.
endmenu
if !KMSAN # avoid false positives from assembly if ARM
source "arch/arm/crypto/Kconfig"
endif if ARM64
source "arch/arm64/crypto/Kconfig"
endif if LOONGARCH
source "arch/loongarch/crypto/Kconfig"
endif if MIPS
source "arch/mips/crypto/Kconfig"
endif if PPC
source "arch/powerpc/crypto/Kconfig"
endif if RISCV
source "arch/riscv/crypto/Kconfig"
endif if S390
source "arch/s390/crypto/Kconfig"
endif if SPARC
source "arch/sparc/crypto/Kconfig"
endif if X86
source "arch/x86/crypto/Kconfig"
endif
endif
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.