summaryrefslogtreecommitdiff
path: root/crypto
diff options
context:
space:
mode:
authorRobert Elliott <elliott@hpe.com>2022-08-20 13:41:44 -0500
committerHerbert Xu <herbert@gondor.apana.org.au>2022-08-26 18:50:42 +0800
commitf1f142ad434883616c313bc93b9f443d496293db (patch)
tree7e47e4923eb13f09ff6fa2e51bcd9961a47020a8 /crypto
parent4a95d4ae98b1610ce1b1df2a36e8955c3f46623e (diff)
downloadlwn-f1f142ad434883616c313bc93b9f443d496293db.tar.gz
lwn-f1f142ad434883616c313bc93b9f443d496293db.zip
crypto: Kconfig - add submenus
Convert each comment section into a submenu: Cryptographic API Crypto core or helper Public-key cryptography Block ciphers Length-preserving ciphers and modes AEAD (authenticated encryption with associated data) ciphers Hashes, digests, and MACs CRCs (cyclic redundancy checks) Compression Random number generation Userspace interface That helps find entries (e.g., searching for a name like SHA512 doesn't just report the location is Main menu -> Cryptography API, leaving you to wade through 153 entries; it points you to the Digests page). Move entries so they fall into the correct submenus and are better sorted. Suggested-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Robert Elliott <elliott@hpe.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto')
-rw-r--r--crypto/Kconfig937
1 files changed, 479 insertions, 458 deletions
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 0349b27075ab..e2e364cfa93e 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -21,7 +21,7 @@ menuconfig CRYPTO
if CRYPTO
-comment "Crypto core or helper"
+menu "Crypto core or helper"
config CRYPTO_FIPS
bool "FIPS 200 compliance"
@@ -235,7 +235,9 @@ config CRYPTO_SIMD
config CRYPTO_ENGINE
tristate
-comment "Public-key cryptography"
+endmenu
+
+menu "Public-key cryptography"
config CRYPTO_RSA
tristate "RSA algorithm"
@@ -316,76 +318,324 @@ config CRYPTO_CURVE25519
select CRYPTO_KPP
select CRYPTO_LIB_CURVE25519_GENERIC
-comment "Authenticated Encryption with Associated Data"
+endmenu
-config CRYPTO_CCM
- tristate "CCM support"
- select CRYPTO_CTR
- select CRYPTO_HASH
- select CRYPTO_AEAD
- select CRYPTO_MANAGER
+menu "Block ciphers"
+
+config CRYPTO_AES
+ tristate "AES cipher algorithms"
+ select CRYPTO_ALGAPI
+ select CRYPTO_LIB_AES
help
- Support for Counter with CBC MAC. Required for IPsec.
+ AES cipher algorithms (FIPS-197). AES uses the Rijndael
+ algorithm.
-config CRYPTO_GCM
- tristate "GCM/GMAC support"
- select CRYPTO_CTR
- select CRYPTO_AEAD
- select CRYPTO_GHASH
- select CRYPTO_NULL
- select CRYPTO_MANAGER
+ Rijndael appears to be consistently a very good performer in
+ both hardware and software across a wide range of computing
+ environments regardless of its use in 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
+
+ See <http://csrc.nist.gov/CryptoToolkit/aes/> for more information.
+
+config CRYPTO_AES_TI
+ tristate "Fixed time AES cipher"
+ select CRYPTO_ALGAPI
+ select CRYPTO_LIB_AES
help
- Support for Galois/Counter Mode (GCM) and Galois Message
- Authentication Code (GMAC). Required for IPSec.
+ 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 for use by 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)
-config CRYPTO_CHACHA20POLY1305
- tristate "ChaCha20-Poly1305 AEAD support"
- select CRYPTO_CHACHA20
- select CRYPTO_POLY1305
- select CRYPTO_AEAD
- select CRYPTO_MANAGER
+ 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 cipher algorithm"
+ depends on CRYPTO_USER_API_ENABLE_OBSOLETE
+ select CRYPTO_ALGAPI
help
- ChaCha20-Poly1305 AEAD support, RFC7539.
+ Anubis cipher algorithm.
- Support for the AEAD wrapper using the ChaCha20 stream cipher combined
- with the Poly1305 authenticator. It is defined in RFC7539 for use in
- IETF protocols.
+ 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.
-config CRYPTO_AEGIS128
- tristate "AEGIS-128 AEAD algorithm"
- select CRYPTO_AEAD
- select CRYPTO_AES # for AES S-box tables
+ See also:
+ <https://www.cosic.esat.kuleuven.be/nessie/reports/>
+ <http://www.larc.usp.br/~pbarreto/AnubisPage.html>
+
+config CRYPTO_ARIA
+ tristate "ARIA cipher algorithm"
+ select CRYPTO_ALGAPI
help
- Support for the AEGIS-128 dedicated AEAD algorithm.
+ ARIA cipher algorithm (RFC5794).
-config CRYPTO_AEGIS128_SIMD
- bool "Support SIMD acceleration for AEGIS-128"
- depends on CRYPTO_AEGIS128 && ((ARM || ARM64) && KERNEL_MODE_NEON)
- default y
+ 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_SEQIV
- tristate "Sequence Number IV Generator"
- select CRYPTO_AEAD
+ See also:
+ <https://seed.kisa.or.kr/kisa/algorithm/EgovAriaInfo.do>
+
+config CRYPTO_BLOWFISH
+ tristate "Blowfish cipher algorithm"
+ 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 for use on "large microprocessors".
+
+ See also:
+ <https://www.schneier.com/blowfish.html>
+
+config CRYPTO_BLOWFISH_COMMON
+ tristate
+ help
+ Common parts of the Blowfish cipher algorithm shared by the
+ generic c and the assembler implementations.
+
+ See also:
+ <https://www.schneier.com/blowfish.html>
+
+config CRYPTO_CAMELLIA
+ tristate "Camellia cipher algorithms"
+ select CRYPTO_ALGAPI
+ help
+ Camellia cipher algorithms module.
+
+ Camellia is a symmetric key block cipher developed jointly
+ at NTT and Mitsubishi Electric Corporation.
+
+ The Camellia specifies three key sizes: 128, 192 and 256 bits.
+
+ See also:
+ <https://info.isl.ntt.co.jp/crypt/eng/camellia/index_s.html>
+
+config CRYPTO_CAST_COMMON
+ tristate
+ help
+ Common parts of the CAST cipher algorithms shared by the
+ generic c and the assembler implementations.
+
+config CRYPTO_CAST5
+ tristate "CAST5 (CAST-128) cipher algorithm"
+ select CRYPTO_ALGAPI
+ select CRYPTO_CAST_COMMON
+ help
+ The CAST5 encryption algorithm (synonymous with CAST-128) is
+ described in RFC2144.
+
+config CRYPTO_CAST6
+ tristate "CAST6 (CAST-256) cipher algorithm"
+ select CRYPTO_ALGAPI
+ select CRYPTO_CAST_COMMON
+ help
+ The CAST6 encryption algorithm (synonymous with CAST-256) is
+ described in RFC2612.
+
+config CRYPTO_DES
+ tristate "DES and Triple DES EDE cipher algorithms"
+ select CRYPTO_ALGAPI
+ select CRYPTO_LIB_DES
+ help
+ DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3).
+
+config CRYPTO_FCRYPT
+ tristate "FCrypt cipher algorithm"
+ select CRYPTO_ALGAPI
select CRYPTO_SKCIPHER
- select CRYPTO_NULL
- select CRYPTO_RNG_DEFAULT
- select CRYPTO_MANAGER
help
- This IV generator generates an IV based on a sequence number by
- xoring it with a salt. This algorithm is mainly useful for CTR
+ FCrypt algorithm used by RxRPC.
-config CRYPTO_ECHAINIV
- tristate "Encrypted Chain IV Generator"
- select CRYPTO_AEAD
- select CRYPTO_NULL
- select CRYPTO_RNG_DEFAULT
+config CRYPTO_KHAZAD
+ tristate "Khazad cipher algorithm"
+ 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.
+
+ See also:
+ <http://www.larc.usp.br/~pbarreto/KhazadPage.html>
+
+config CRYPTO_SEED
+ tristate "SEED cipher algorithm"
+ depends on CRYPTO_USER_API_ENABLE_OBSOLETE
+ select CRYPTO_ALGAPI
+ help
+ SEED cipher algorithm (RFC4269).
+
+ 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.
+
+ See also:
+ <http://www.kisa.or.kr/kisa/seed/jsp/seed_eng.jsp>
+
+config CRYPTO_SERPENT
+ tristate "Serpent cipher algorithm"
+ select CRYPTO_ALGAPI
+ help
+ Serpent cipher algorithm, by Anderson, Biham & Knudsen.
+
+ Keys are allowed to be from 0 to 256 bits in length, in steps
+ of 8 bits.
+
+ See also:
+ <https://www.cl.cam.ac.uk/~rja14/serpent.html>
+
+config CRYPTO_SM4
+ tristate
+
+config CRYPTO_SM4_GENERIC
+ tristate "SM4 cipher algorithm"
+ select CRYPTO_ALGAPI
+ select CRYPTO_SM4
+ help
+ SM4 cipher algorithms (OSCCA GB/T 32907-2016).
+
+ 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 for use in protecting wireless
+ networks, and is 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.
+
+ See also: <https://eprint.iacr.org/2008/329.pdf>
+
+ If unsure, say N.
+
+config CRYPTO_TEA
+ tristate "TEA, XTEA and XETA cipher algorithms"
+ depends on CRYPTO_USER_API_ENABLE_OBSOLETE
+ select CRYPTO_ALGAPI
+ help
+ TEA cipher algorithm.
+
+ Tiny Encryption Algorithm is a simple cipher that uses
+ many rounds for security. It is very fast and uses
+ little memory.
+
+ Xtendend Tiny Encryption Algorithm is a modification to
+ the TEA algorithm to address a potential key weakness
+ in the TEA algorithm.
+
+ Xtendend Encryption Tiny Algorithm is a mis-implementation
+ of the XTEA algorithm for compatibility purposes.
+
+config CRYPTO_TWOFISH
+ tristate "Twofish cipher algorithm"
+ select CRYPTO_ALGAPI
+ select CRYPTO_TWOFISH_COMMON
+ help
+ Twofish cipher algorithm.
+
+ 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.
+
+ See also:
+ <https://www.schneier.com/twofish.html>
+
+config CRYPTO_TWOFISH_COMMON
+ tristate
+ help
+ Common parts of the Twofish cipher algorithm shared by the
+ generic c and the assembler implementations.
+
+endmenu
+
+menu "Length-preserving ciphers and modes"
+
+config CRYPTO_ADIANTUM
+ tristate "Adiantum support"
+ select CRYPTO_CHACHA20
+ select CRYPTO_LIB_POLY1305_GENERIC
+ select CRYPTO_NHPOLY1305
select CRYPTO_MANAGER
help
- 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.
+ Adiantum is a tweakable, length-preserving encryption mode
+ 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.
-comment "Block modes"
+ 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 cipher algorithm"
+ 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 stream cipher algorithms"
+ 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 for use in IETF protocols.
+ This is the portable C implementation of ChaCha20. See also:
+ <https://cr.yp.to/chacha/chacha-20080128.pdf>
+
+ 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 also:
+ <https://cr.yp.to/snuffle/xsalsa-20081128.pdf>
+
+ 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_CBC
tristate "CBC support"
@@ -435,6 +685,25 @@ config CRYPTO_ECB
This is the simplest block cipher algorithm. It simply encrypts
the input block by block.
+config CRYPTO_HCTR2
+ tristate "HCTR2 support"
+ select CRYPTO_XCTR
+ select CRYPTO_POLYVAL
+ select CRYPTO_MANAGER
+ help
+ HCTR2 is a length-preserving encryption 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.
+
+config CRYPTO_KEYWRAP
+ tristate "Key wrapping support"
+ select CRYPTO_SKCIPHER
+ select CRYPTO_MANAGER
+ help
+ Support for key wrapping (NIST SP800-38F / RFC3394) without
+ padding.
+
config CRYPTO_LRW
tristate "LRW support"
select CRYPTO_SKCIPHER
@@ -487,53 +756,81 @@ config CRYPTO_XTS
key size 256, 384 or 512 bits. This implementation currently
can't handle a sectorsize which is not a multiple of 16 bytes.
-config CRYPTO_KEYWRAP
- tristate "Key wrapping support"
- select CRYPTO_SKCIPHER
- select CRYPTO_MANAGER
- help
- Support for key wrapping (NIST SP800-38F / RFC3394) without
- padding.
-
config CRYPTO_NHPOLY1305
tristate
select CRYPTO_HASH
select CRYPTO_LIB_POLY1305_GENERIC
-config CRYPTO_ADIANTUM
- tristate "Adiantum support"
+endmenu
+
+menu "AEAD (authenticated encryption with associated data) ciphers"
+
+config CRYPTO_AEGIS128
+ tristate "AEGIS-128 AEAD algorithm"
+ select CRYPTO_AEAD
+ select CRYPTO_AES # for AES S-box tables
+ help
+ Support for the AEGIS-128 dedicated AEAD algorithm.
+
+config CRYPTO_AEGIS128_SIMD
+ bool "Support SIMD acceleration for AEGIS-128"
+ depends on CRYPTO_AEGIS128 && ((ARM || ARM64) && KERNEL_MODE_NEON)
+ default y
+
+config CRYPTO_CHACHA20POLY1305
+ tristate "ChaCha20-Poly1305 AEAD support"
select CRYPTO_CHACHA20
- select CRYPTO_LIB_POLY1305_GENERIC
- select CRYPTO_NHPOLY1305
+ select CRYPTO_POLY1305
+ select CRYPTO_AEAD
select CRYPTO_MANAGER
help
- Adiantum is a tweakable, length-preserving encryption mode
- 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.
+ ChaCha20-Poly1305 AEAD support, RFC7539.
- 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.
+ Support for the AEAD wrapper using the ChaCha20 stream cipher combined
+ with the Poly1305 authenticator. It is defined in RFC7539 for use in
+ IETF protocols.
- If unsure, say N.
+config CRYPTO_CCM
+ tristate "CCM support"
+ select CRYPTO_CTR
+ select CRYPTO_HASH
+ select CRYPTO_AEAD
+ select CRYPTO_MANAGER
+ help
+ Support for Counter with CBC MAC. Required for IPsec.
-config CRYPTO_HCTR2
- tristate "HCTR2 support"
- select CRYPTO_XCTR
- select CRYPTO_POLYVAL
+config CRYPTO_GCM
+ tristate "GCM/GMAC support"
+ select CRYPTO_CTR
+ select CRYPTO_AEAD
+ select CRYPTO_GHASH
+ select CRYPTO_NULL
select CRYPTO_MANAGER
help
- HCTR2 is a length-preserving encryption 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.
+ Support for Galois/Counter Mode (GCM) and Galois Message
+ Authentication Code (GMAC). Required for IPSec.
+
+config CRYPTO_SEQIV
+ tristate "Sequence Number IV Generator"
+ select CRYPTO_AEAD
+ select CRYPTO_SKCIPHER
+ select CRYPTO_NULL
+ select CRYPTO_RNG_DEFAULT
+ select CRYPTO_MANAGER
+ help
+ This IV generator generates an IV based on a sequence number by
+ xoring it with a salt. This algorithm is mainly useful for CTR
+
+config CRYPTO_ECHAINIV
+ tristate "Encrypted Chain IV Generator"
+ select CRYPTO_AEAD
+ select CRYPTO_NULL
+ select CRYPTO_RNG_DEFAULT
+ select CRYPTO_MANAGER
+ help
+ 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 "ESSIV support for block encryption"
@@ -563,74 +860,9 @@ config CRYPTO_ESSIV
combined with ESSIV the only feasible mode for h/w accelerated
block encryption)
-comment "Hash modes"
-
-config CRYPTO_CMAC
- tristate "CMAC support"
- select CRYPTO_HASH
- select CRYPTO_MANAGER
- help
- Cipher-based Message Authentication Code (CMAC) specified by
- The National Institute of Standards and Technology (NIST).
-
- https://tools.ietf.org/html/rfc4493
- http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
-
-config CRYPTO_HMAC
- tristate "HMAC support"
- select CRYPTO_HASH
- select CRYPTO_MANAGER
- help
- HMAC: Keyed-Hashing for Message Authentication (RFC2104).
- This is required for IPSec.
-
-config CRYPTO_XCBC
- tristate "XCBC support"
- select CRYPTO_HASH
- select CRYPTO_MANAGER
- help
- XCBC: Keyed-Hashing with encryption algorithm
- https://www.ietf.org/rfc/rfc3566.txt
- http://csrc.nist.gov/encryption/modes/proposedmodes/
- xcbc-mac/xcbc-mac-spec.pdf
-
-config CRYPTO_VMAC
- tristate "VMAC support"
- select CRYPTO_HASH
- select CRYPTO_MANAGER
- help
- VMAC is a message authentication algorithm designed for
- very high speed on 64-bit architectures.
-
- See also:
- <https://fastcrypto.org/vmac>
-
-comment "Digest"
-
-config CRYPTO_CRC32C
- tristate "CRC32c CRC algorithm"
- select CRYPTO_HASH
- select CRC32
- help
- Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
- by iSCSI for header and data digests and by others.
- See Castagnoli93. Module will be crc32c.
-
-config CRYPTO_CRC32
- tristate "CRC32 CRC algorithm"
- select CRYPTO_HASH
- select CRC32
- help
- CRC-32-IEEE 802.3 cyclic redundancy-check algorithm.
- Shash crypto api wrappers to crc32_le function.
+endmenu
-config CRYPTO_XXHASH
- tristate "xxHash hash algorithm"
- select CRYPTO_HASH
- select XXHASH
- help
- xxHash non-cryptographic hash algorithm. Extremely fast, working at
- speeds close to RAM limits.
+menu "Hashes, digests, and MACs"
config CRYPTO_BLAKE2B
tristate "BLAKE2b digest algorithm"
@@ -649,18 +881,16 @@ config CRYPTO_BLAKE2B
See https://blake2.net for further information.
-config CRYPTO_CRCT10DIF
- tristate "CRCT10DIF algorithm"
+config CRYPTO_CMAC
+ tristate "CMAC support"
select CRYPTO_HASH
+ select CRYPTO_MANAGER
help
- CRC T10 Data Integrity Field computation is being cast as
- a crypto transform. This allows for faster crc t10 diff
- transforms to be used if they are available.
+ Cipher-based Message Authentication Code (CMAC) specified by
+ The National Institute of Standards and Technology (NIST).
-config CRYPTO_CRC64_ROCKSOFT
- tristate "Rocksoft Model CRC64 algorithm"
- depends on CRC64
- select CRYPTO_HASH
+ https://tools.ietf.org/html/rfc4493
+ http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
config CRYPTO_GHASH
tristate "GHASH hash function"
@@ -670,24 +900,13 @@ config CRYPTO_GHASH
GHASH is the hash function used in GCM (Galois/Counter Mode).
It is not a general-purpose cryptographic hash function.
-config CRYPTO_POLYVAL
- tristate
- select CRYPTO_GF128MUL
- select CRYPTO_HASH
- help
- POLYVAL is the hash function used in HCTR2. It is not a general-purpose
- cryptographic hash function.
-
-config CRYPTO_POLY1305
- tristate "Poly1305 authenticator algorithm"
+config CRYPTO_HMAC
+ tristate "HMAC support"
select CRYPTO_HASH
- select CRYPTO_LIB_POLY1305_GENERIC
+ select CRYPTO_MANAGER
help
- Poly1305 authenticator algorithm, RFC7539.
-
- Poly1305 is an authenticator algorithm designed by Daniel J. Bernstein.
- It is used for the ChaCha20-Poly1305 AEAD, specified in RFC7539 for use
- in IETF protocols. This is the portable C implementation of Poly1305.
+ HMAC: Keyed-Hashing for Message Authentication (RFC2104).
+ This is required for IPSec.
config CRYPTO_MD4
tristate "MD4 digest algorithm"
@@ -710,6 +929,25 @@ config CRYPTO_MICHAEL_MIC
should not be used for other purposes because of the weakness
of the algorithm.
+config CRYPTO_POLYVAL
+ tristate
+ select CRYPTO_GF128MUL
+ select CRYPTO_HASH
+ help
+ POLYVAL is the hash function used in HCTR2. It is not a general-purpose
+ cryptographic hash function.
+
+config CRYPTO_POLY1305
+ tristate "Poly1305 authenticator algorithm"
+ select CRYPTO_HASH
+ select CRYPTO_LIB_POLY1305_GENERIC
+ help
+ Poly1305 authenticator algorithm, RFC7539.
+
+ Poly1305 is an authenticator algorithm designed by Daniel J. Bernstein.
+ It is used for the ChaCha20-Poly1305 AEAD, specified in RFC7539 for use
+ in IETF protocols. This is the portable C implementation of Poly1305.
+
config CRYPTO_RMD160
tristate "RIPEMD-160 digest algorithm"
select CRYPTO_HASH
@@ -796,6 +1034,17 @@ config CRYPTO_STREEBOG
https://tc26.ru/upload/iblock/fed/feddbb4d26b685903faa2ba11aea43f6.pdf
https://tools.ietf.org/html/rfc6986
+config CRYPTO_VMAC
+ tristate "VMAC support"
+ select CRYPTO_HASH
+ select CRYPTO_MANAGER
+ help
+ VMAC is a message authentication algorithm designed for
+ very high speed on 64-bit architectures.
+
+ See also:
+ <https://fastcrypto.org/vmac>
+
config CRYPTO_WP512
tristate "Whirlpool digest algorithms"
select CRYPTO_HASH
@@ -808,296 +1057,61 @@ config CRYPTO_WP512
See also:
<http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html>
-comment "Ciphers"
-
-config CRYPTO_AES
- tristate "AES cipher algorithms"
- select CRYPTO_ALGAPI
- select CRYPTO_LIB_AES
- help
- AES cipher algorithms (FIPS-197). AES uses the Rijndael
- algorithm.
-
- Rijndael appears to be consistently a very good performer in
- both hardware and software across a wide range of computing
- environments regardless of its use in 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
-
- See <http://csrc.nist.gov/CryptoToolkit/aes/> for more information.
-
-config CRYPTO_AES_TI
- tristate "Fixed time AES cipher"
- select CRYPTO_ALGAPI
- select CRYPTO_LIB_AES
- help
- 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 for use by 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 cipher algorithm"
- 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.
-
- See also:
- <https://www.cosic.esat.kuleuven.be/nessie/reports/>
- <http://www.larc.usp.br/~pbarreto/AnubisPage.html>
-
-config CRYPTO_ARC4
- tristate "ARC4 cipher algorithm"
- 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_BLOWFISH
- tristate "Blowfish cipher algorithm"
- 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 for use on "large microprocessors".
-
- See also:
- <https://www.schneier.com/blowfish.html>
-
-config CRYPTO_BLOWFISH_COMMON
- tristate
- help
- Common parts of the Blowfish cipher algorithm shared by the
- generic c and the assembler implementations.
-
- See also:
- <https://www.schneier.com/blowfish.html>
-
-config CRYPTO_CAMELLIA
- tristate "Camellia cipher algorithms"
- select CRYPTO_ALGAPI
- help
- Camellia cipher algorithms module.
-
- Camellia is a symmetric key block cipher developed jointly
- at NTT and Mitsubishi Electric Corporation.
-
- The Camellia specifies three key sizes: 128, 192 and 256 bits.
-
- See also:
- <https://info.isl.ntt.co.jp/crypt/eng/camellia/index_s.html>
-
-config CRYPTO_CAST_COMMON
- tristate
- help
- Common parts of the CAST cipher algorithms shared by the
- generic c and the assembler implementations.
-
-config CRYPTO_CAST5
- tristate "CAST5 (CAST-128) cipher algorithm"
- select CRYPTO_ALGAPI
- select CRYPTO_CAST_COMMON
- help
- The CAST5 encryption algorithm (synonymous with CAST-128) is
- described in RFC2144.
-
-config CRYPTO_CAST6
- tristate "CAST6 (CAST-256) cipher algorithm"
- select CRYPTO_ALGAPI
- select CRYPTO_CAST_COMMON
- help
- The CAST6 encryption algorithm (synonymous with CAST-256) is
- described in RFC2612.
-
-config CRYPTO_DES
- tristate "DES and Triple DES EDE cipher algorithms"
- select CRYPTO_ALGAPI
- select CRYPTO_LIB_DES
- help
- DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3).
-
-config CRYPTO_FCRYPT
- tristate "FCrypt cipher algorithm"
- select CRYPTO_ALGAPI
- select CRYPTO_SKCIPHER
- help
- FCrypt algorithm used by RxRPC.
-
-config CRYPTO_KHAZAD
- tristate "Khazad cipher algorithm"
- 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.
-
- See also:
- <http://www.larc.usp.br/~pbarreto/KhazadPage.html>
-
-config CRYPTO_CHACHA20
- tristate "ChaCha stream cipher algorithms"
- 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 for use in IETF protocols.
- This is the portable C implementation of ChaCha20. See also:
- <https://cr.yp.to/chacha/chacha-20080128.pdf>
-
- 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 also:
- <https://cr.yp.to/snuffle/xsalsa-20081128.pdf>
-
- 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_SEED
- tristate "SEED cipher algorithm"
- depends on CRYPTO_USER_API_ENABLE_OBSOLETE
- select CRYPTO_ALGAPI
- help
- SEED cipher algorithm (RFC4269).
-
- 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.
-
- See also:
- <http://www.kisa.or.kr/kisa/seed/jsp/seed_eng.jsp>
-
-config CRYPTO_ARIA
- tristate "ARIA cipher algorithm"
- select CRYPTO_ALGAPI
+config CRYPTO_XCBC
+ tristate "XCBC support"
+ select CRYPTO_HASH
+ select CRYPTO_MANAGER
help
- ARIA cipher algorithm (RFC5794).
-
- 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.
-
- See also:
- <https://seed.kisa.or.kr/kisa/algorithm/EgovAriaInfo.do>
+ XCBC: Keyed-Hashing with encryption algorithm
+ https://www.ietf.org/rfc/rfc3566.txt
+ http://csrc.nist.gov/encryption/modes/proposedmodes/
+ xcbc-mac/xcbc-mac-spec.pdf
-config CRYPTO_SERPENT
- tristate "Serpent cipher algorithm"
- select CRYPTO_ALGAPI
+config CRYPTO_XXHASH
+ tristate "xxHash hash algorithm"
+ select CRYPTO_HASH
+ select XXHASH
help
- Serpent cipher algorithm, by Anderson, Biham & Knudsen.
+ xxHash non-cryptographic hash algorithm. Extremely fast, working at
+ speeds close to RAM limits.
- Keys are allowed to be from 0 to 256 bits in length, in steps
- of 8 bits.
+endmenu
- See also:
- <https://www.cl.cam.ac.uk/~rja14/serpent.html>
+menu "CRCs (cyclic redundancy checks)"
-config CRYPTO_SM4
- tristate
-
-config CRYPTO_SM4_GENERIC
- tristate "SM4 cipher algorithm"
- select CRYPTO_ALGAPI
- select CRYPTO_SM4
+config CRYPTO_CRC32C
+ tristate "CRC32c CRC algorithm"
+ select CRYPTO_HASH
+ select CRC32
help
- SM4 cipher algorithms (OSCCA GB/T 32907-2016).
-
- 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 for use in protecting wireless
- networks, and is 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.
-
- See also: <https://eprint.iacr.org/2008/329.pdf>
-
- If unsure, say N.
+ Castagnoli, et al Cyclic Redundancy-Check Algorithm. Used
+ by iSCSI for header and data digests and by others.
+ See Castagnoli93. Module will be crc32c.
-config CRYPTO_TEA
- tristate "TEA, XTEA and XETA cipher algorithms"
- depends on CRYPTO_USER_API_ENABLE_OBSOLETE
- select CRYPTO_ALGAPI
+config CRYPTO_CRC32
+ tristate "CRC32 CRC algorithm"
+ select CRYPTO_HASH
+ select CRC32
help
- TEA cipher algorithm.
-
- Tiny Encryption Algorithm is a simple cipher that uses
- many rounds for security. It is very fast and uses
- little memory.
-
- Xtendend Tiny Encryption Algorithm is a modification to
- the TEA algorithm to address a potential key weakness
- in the TEA algorithm.
-
- Xtendend Encryption Tiny Algorithm is a mis-implementation
- of the XTEA algorithm for compatibility purposes.
+ CRC-32-IEEE 802.3 cyclic redundancy-check algorithm.
+ Shash crypto api wrappers to crc32_le function.
-config CRYPTO_TWOFISH
- tristate "Twofish cipher algorithm"
- select CRYPTO_ALGAPI
- select CRYPTO_TWOFISH_COMMON
+config CRYPTO_CRCT10DIF
+ tristate "CRCT10DIF algorithm"
+ select CRYPTO_HASH
help
- Twofish cipher algorithm.
-
- 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.
+ CRC T10 Data Integrity Field computation is being cast as
+ a crypto transform. This allows for faster crc t10 diff
+ transforms to be used if they are available.
- See also:
- <https://www.schneier.com/twofish.html>
+config CRYPTO_CRC64_ROCKSOFT
+ tristate "Rocksoft Model CRC64 algorithm"
+ depends on CRC64
+ select CRYPTO_HASH
-config CRYPTO_TWOFISH_COMMON
- tristate
- help
- Common parts of the Twofish cipher algorithm shared by the
- generic c and the assembler implementations.
+endmenu
-comment "Compression"
+menu "Compression"
config CRYPTO_DEFLATE
tristate "Deflate compression algorithm"
@@ -1156,7 +1170,9 @@ config CRYPTO_ZSTD
help
This is the zstd algorithm.
-comment "Random Number Generation"
+endmenu
+
+menu "Random number generation"
config CRYPTO_ANSI_CPRNG
tristate "Pseudo Random Number Generation for Cryptographic modules"
@@ -1218,6 +1234,9 @@ config CRYPTO_KDF800108_CTR
select CRYPTO_HMAC
select CRYPTO_SHA256
+endmenu
+menu "User-space interface"
+
config CRYPTO_USER_API
tristate
@@ -1289,6 +1308,8 @@ config CRYPTO_STATS
- encrypt/decrypt/sign/verify numbers for asymmetric operations
- generate/seed numbers for rng operations
+endmenu
+
config CRYPTO_HASH_INFO
bool