I'm using an Ubuntu-based system, and I'm having difficulty determining what ciphers and cipher modes are available to me.
The cryptsetup man page says:
"See /proc/crypto for a list of available options. You might need to load additional kernel crypto modules in order to get more options."
My /proc/crypto has very little in it. How do I find out which extra kernel crypto modules are available for me to load?
There are many, many documents and man pages to read through, but one document that might particularly interest you is the LUKS On-Disk Format Specification (PDF).
Appendix B (which is, naturally, near the end) says,
Cipher and Hash specification registry
Even if the cipher-name and cipher-mode strings are not interpreted by any LUKS operation, they must have the same meaning for all implementations to achieve compatibility among different LUKS-based implementations. LUKS has to ensure that the underlaying cipher system can utilise the cipher name and cipher mode strings, and as these strings might not always be native to the cipher system, LUKS might need to map them into something appropriate.
Valid cipher names are listed in Table 1.
Valid cipher modes are listed in Table 2. By contract, cipher modes using IVs and tweaks must start from the all-zero IV / tweak. This applies for all calls to the encrypt / decrypt primitives especially when handling key material. Further, these IVs / tweaks cipher modes usually cut the cipher stream into independent blocks by reseeding tweaks / IVs at sector boundaries. The all-zero IV / tweak requirement for the first encrypted / decrypted block is equivalent to the requirement that the first block is defined to rest at sector 0.
Table 3 lists valid hash specs for hash-spec field. A compliant implementation does not have to support all cipher, cipher mode or hash specifications.
Table 1: Valid cipher names
- aes - Advanced Encryption Standard - FIPS PUB 197
- twofish - Twofish: A 128-Bit Block Cipher - http://www.schneier.com/paper-twofish-paper.html (See below)
- serpent - http://www.cl.cam.ac.uk/~rja14/serpent.html
- cast5 - RFC 2144
- cast6 - RFC 2612
Table 2: Valid cipher modes
- ecb - The cipher output is used directly
- cbc-plain - The cipher is operated in CBC mode. The CBC chaining is cut every sector, and reinitialised with the sector number as initial vector (converted to 32-bit and to little-endian). This mode is specified in [Fru05b], Chapter 4.
- cbc-essiv:hash - The cipher is operated in ESSIV mode using hash for generating the IV key for the original key. For instance, when using sha256 as hash, the cipher mode spec is “cbcessiv:sha256”. ESSIV is specified in [Fru05b], Chapter 4.
- xts-plain64 - http://grouper.ieee.org/groups/1619/email/pdf00086.pdf, plain64 is 64-bit version of plain initial vector
Table 3: Valid hash specifications
- sha1 - RFC 3174 - US Secure Hash Algorithm 1 (SHA1)
- sha256 - SHA variant according to FIPS 180-2
- sha512 - SHA variant according to FIPS 180-2
- ripemd160 - http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html (See below)
Editor’s Note: The above is copied from the specification. Subsequent to its writing, these documents’ URLs have changed:
The 5.1 kernel, current at the time I write this, has two different formats the for cipher string, the "old" format and the "new" format. Everything in this question so far, and apparently all docs too, deals with the "old" format, so I'll describe it here. This is for just encryption. If using integrity with dm-crypt, then one must consider AEAD ciphers and it gets even more complicated.
The format parsed by the kernel is "cipher[:keycount]-mode-ivmode[:ivopts]". Examples: aes-xts-plain64, blowfish-cbc-essiv:sha256, aes:64-cbc-lmk.
cipher
The cipher to use, examples are aes, anubis, twofish, arc4, etc. The kernel dm-crypt driver does not have a list of ciphers. This is passed through to the Linux Crypto API, so any suitable cipher supported by the kernel can be used.
keycount
Optional power of two number of keys to use with cipher. This defaults to 1 for everything except the lmk ivmode, where it defaults to 64. This really only applies to LMK and values other than 1 will will not work properly with other modes.
mode The block chaining mode to use with the cipher. Examples are ecb, cbc, xts. Other than knowing that ecb uses no IV, the md-crypt driver passes this through to the Linux Crypto API and can use any chaining mode supported by the kernel.
ivmode The algorithm used to generate the initialization vector (IV) for each sector. In typical symmetric key encryption, unlike dm-crypt, the IV is another bit of data passed into the cipher along with the key when encrypting or decrypting. There is just one IV passed in for the entire operation. Since dm-crypt needs to be able to read and write each sector individually, it does not encrypt the entire disk as a single operation. Instead, there is an IV for each sector. Rather than passing in the IV as data, an algorithm for creating the IVs is specified here. This isn't part of the Linux Crypto API, since IV generation isn't done by the cipher, and the allowed ivmode values are defined the dm-crypt driver. They are:
plain, plain64, plain64be, benbi
These simply use the sector number, in various formats, as the IV. Meant for block modes like XTS that are designed to resist attacks like watermarking when using a simple and predictable IV. plain64 appears to be the most commonly recommended.null IV is always zero. For testing and backward compatibility, you shouldn't use this.lmk Compatible with the Loop-AES encryption scheme.tcw Compatible with TrueCrypt.essiv Uses sector number encrypted with a hash of the key. Meant for modes, like CBC, that are not resistant to various attacks when using a simple IV like plain64.ivopts The hash to be used with essiv ivmode, ignored for all other modes.
As a special case, "cipher-plain" or just "cipher" are interpreted as "cipher-cbc-plain". Another special case is that ecb mode has no ivmode to specify.
/proc/cryptoWith respect to /proc/crypto, only the cipher and mode are relevant. dm-crypt with construct a Crypto API specification of the form "mode(cipher)" and request this from the kernel. This is what one should look for in /proc/crypto as the name for a skcipher. Example:
name : xts(aes)
driver : xts-aes-aesni
module : kernel
priority : 401
refcnt : 1
selftest : passed
internal : no
type : skcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
chunksize : 16
walksize : 16
The type of skcipher indicates this a symmetric key cipher, what dm-crypt uses, and the name of xts(aes) would be written aes-xts when specified with dm-crypt. The keysize fields also tell us what key sizes can be used with this cipher.
If this was from a module, the module name might show up in the module line. However, many ciphers (usually those in software that don't have any hardware specific code) are implement as a generic cipher that is combined with generic block chaining code to produce the final skcipher. For example:
name : xts(anubis)
driver : xts(ecb(anubis-generic))
module : kernel
type : skcipher
name : anubis
driver : anubis-generic
module : anubis
type : cipher
In this case the anubis cipher is combined with the kernel XTS block chaining mode code to produce the final cipher xts(anbuis), which has been assigned a module of kernel. But in order to have this available we need the generic anubis cipher, which is from the anubis module. Most ciphers have a module alias of "crypto-cipher" that can be used to load them, e.g. modprobe crypto-anubis would load module that provides the anubis cipher.
When using the cryptsetup benchmark command, only the cipher and mode matter, since that is all that is benchmarked. If mode is not specified it defaults to CBC. The ivmode is totally ignored. Thus, for benchmarking, aes, aes-cbc, and aes-cbc-foobar are all equivalent.
You can list the ciphers supported by your kernels with the following command,
[root@arif]# ls /lib/modules/[your kernel version]/kernel/crypto/
algif_rng.ko.xz blowfish_common.ko.xz cmac.ko.xz cts.ko.xz gf128mul.ko.xz michael_mic.ko.xz rsa_generic.ko.xz tgr192.ko.xz xts.ko.xz
ansi_cprng.ko.xz blowfish_generic.ko.xz crc32_generic.ko.xz deflate.ko.xz ghash-generic.ko.xz pcbc.ko.xz salsa20_generic.ko.xz twofish_common.ko.xz zlib.ko.xz
anubis.ko.xz camellia_generic.ko.xz crct10dif_common.ko.xz des_generic.ko.xz jitterentropy_rng.ko.xz pcrypt.ko.xz seed.ko.xz twofish_generic.ko.xz
arc4.ko.xz cast5_generic.ko.xz crct10dif_generic.ko.xz dh_generic.ko.xz khazad.ko.xz rmd128.ko.xz serpent_generic.ko.xz vmac.ko.xz
async_tx cast6_generic.ko.xz cryptd.ko.xz drbg.ko.xz lrw.ko.xz rmd160.ko.xz sha512_generic.ko.xz wp512.ko.xz
authencesn.ko.xz cast_common.ko.xz crypto_null.ko.xz fcrypt.ko.xz mcryptd.ko.xz rmd256.ko.xz tcrypt.ko.xz xcbc.ko.xz
authenc.ko.xz ccm.ko.xz crypto_user.ko.xz gcm.ko.xz md4.ko.xz rmd320.ko.xz tea.ko.xz xor.ko.xz
You can list the ciphers and hashes you can use and their I/O comparison by for luks by the following command,
[root@arif arif]# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 289342 iterations per second for 256-bit key
PBKDF2-sha256 353293 iterations per second for 256-bit key
PBKDF2-sha512 227555 iterations per second for 256-bit key
PBKDF2-ripemd160 233224 iterations per second for 256-bit key
PBKDF2-whirlpool 236165 iterations per second for 256-bit key
argon2i 4 iterations, 917485 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 951672 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 642.2 MiB/s 2495.8 MiB/s
serpent-cbc 128b 89.3 MiB/s 542.6 MiB/s
twofish-cbc 128b 100.4 MiB/s 343.1 MiB/s
aes-cbc 256b 477.2 MiB/s 1979.2 MiB/s
serpent-cbc 256b 89.3 MiB/s 538.9 MiB/s
twofish-cbc 256b 173.3 MiB/s 343.1 MiB/s
aes-xts 256b 1668.0 MiB/s 1664.1 MiB/s
serpent-xts 256b 535.7 MiB/s 523.4 MiB/s
twofish-xts 256b 332.6 MiB/s 339.8 MiB/s
aes-xts 512b 1384.5 MiB/s 1380.7 MiB/s
serpent-xts 512b 539.3 MiB/s 524.4 MiB/s
twofish-xts 512b 335.0 MiB/s 340.1 MiB/s
You can compare specific ciphers by the following command,
[root@arif]# ciphers="aes-xts serpent-xts anubis-xts"
[root@arif]# echo "# Algorithm | Key | Encryption | Decryption";for i in $ciphers ; do cryptsetup benchmark --cipher $i|tail -n 1; done
# Algorithm | Key | Encryption | Decryption
aes-xts 256b 1613.9 MiB/s 1642.8 MiB/s
serpent-xts 256b 538.9 MiB/s 521.9 MiB/s
anubis-xts 256b 182.0 MiB/s 182.1 MiB/s
@Xen2050 asks:
How do you know which of the 58 files above convert into cryptsetup compatible cipher modes? It can't be the benchmark command since it doesn't list anubis-xts...
arif's idea of "looking at modules" is quite good for figuring out what generic strings the Crypto API would accept (as we've learned in TrentP's answer), but it does not Xen's question. The config can!
less -- it could be less /proc/config.gz, or sometimes less /config/config-$(uname -r)./CONFIG_CRYPTO to skip to the part where, well, crypto stuff is./Block ciphers to skip to the block cipher part. These ones, changed to lowercase, you can use in the first part.Actually this still isn't the full picture, because some modules take care of multiple algorithms (e.g. chacha20 takes care of xchacha12). At this point you need to circle back to /proc/crypto, but with the foresight of loading all the modules first:
ver=$(uname -r)
# could be in /lib instead, change this if it fails
pushd /usr/lib/modules/"$ver"/kernel/crypto
modules=(*.ko*)
popd
sudo modprobe "${modules[@]%.ko*}"
Then we can maybe make more sense of /proc/crypto by only reading the relevant parts (name and type): grep -E "^name|^type" /proc/crypto.
(Actually this still isn't the full picture, because adiantium isn't being shown...)
Stream ciphers don't need a block mode of operation (second part of the name). One example (that happens to also be an AEAD) is aegis128-random from the LUKS2 format document, luks2_doc_wip.pdf.
