Summary: I can run
cryptsetup benchmark and sort the results, but seek guidance in their interpretation. E.g., should I give more weight to encryption speed or decryption speed? Should key-derivation speed override either? And how should my usecase affect how I weight/interpret results?
Pointers to doc are appreciated: I have websearched, but haven't seen anything definitive-looking. Particularly, this does not seem to be
- discussed in relevant sections of the ArchWiki
I'm preparing to reinstall OS on a 2007-ish laptop (so presumably no processor support for AES), this time with LUKS+LVM2. (It's my one remaining box with
Plain Old Partitions.) I don't have time to run several loops of the sequence [install LUKS+LVM2+OS, run a real disk benchmark, measure results], though that would obviously give much more empirical guidance. Instead, I'm trying to choose a rational (even optimal :-) LUKS cipher specification string "up front" using
cryptsetup benchmark, though I know that one "cannot directly predict real storage encryption speed from it".
When this box runs
sudo cryptsetup benchmark it outputs (after tweaking to label and separate the issues and to sort by speed decreasing):
# key derivation: PBKDF2-sha1 557753 iterations per second PBKDF2-sha256 356173 iterations per second PBKDF2-ripemd160 336082 iterations per second PBKDF2-sha512 256000 iterations per second PBKDF2-whirlpool 112219 iterations per second # encryption: # Algorithm | Key | Encryption serpent-xts 512b 144.7 MiB/s serpent-xts 256b 144.0 MiB/s twofish-xts 256b 132.1 MiB/s twofish-xts 512b 132.0 MiB/s aes-xts 256b 128.4 MiB/s aes-cbc 128b 109.7 MiB/s twofish-cbc 256b 108.2 MiB/s twofish-cbc 128b 107.9 MiB/s aes-xts 512b 96.7 MiB/s aes-cbc 256b 86.5 MiB/s serpent-cbc 256b 42.1 MiB/s serpent-cbc 128b 42.1 MiB/s # decryption: # Algorithm | Key | Decryption serpent-cbc 256b 160.0 MiB/s serpent-cbc 128b 159.5 MiB/s serpent-xts 512b 149.0 MiB/s serpent-xts 256b 148.4 MiB/s twofish-cbc 256b 142.1 MiB/s twofish-cbc 128b 141.6 MiB/s twofish-xts 256b 133.5 MiB/s twofish-xts 512b 133.4 MiB/s aes-cbc 128b 127.5 MiB/s aes-xts 256b 126.0 MiB/s aes-cbc 256b 96.0 MiB/s aes-xts 512b 95.2 MiB/s
The above results show
serpent-xts/512is 3rd fastest
- key derivation:
sha1is significantly faster than
sha256is significantly faster than
Less certainly, I believe
sha1is being retired, so for compatibility going forward, I should deweight (to zero) the significant KDF speed advantage of
- "For the normal use-case of an authorized user [on a workstation, the key derivation function] will only need to be calculated once per session," so I should deweight the significant KDF advantage of
So a specific question is:
- Should I give more weight to the significant speed advantage of
sha256in key derivation (
|356173 - 256000| / ((356173 + 256000)/2)~= 0.327), or to the modest speed advantage of
sha512(which I'm assuming is also more secure) in both decryption and encryption?
A more general question is:
- How should one's usecase affect one's weighting of the importance of speed in key derivation, decryption, and encryption? E.g., will a headless server spend more or less time decrypting (or whatever) than a headful workstation? I'm assuming that decryption is done on read and encryption on write, but I don't know about how one's usecase affects the relative incidence/weight of read and write.
FWIW, the box I'm setting up will be my second-string headful production box for now, so it basically needs to
- run an editor and a browser
- make SSH connections
- play video and music
- be a loaner for folks who want to try Linux
- be ready to go if I hose my first-string production laptop
(It will be running Debian, if that makes a difference.) Of course, I generally prefer faster performance to slower (and more reliability to less) but I'm obviously willing to pay some price for security.
Even more general questions are:
Can one generally rank importance of speed of key derivation, decryption, and encryption? I'm guessing KDF speed is much less important, but that decryption and encryption speeds are of equal weight for most usecases. (But ICBW.)
I know that default, no-argument runs of
cryptsetup benchmark"[measure only a] few common configurations" and that to "benchmark other ciphers or modes, you need to specify
--hashfor KDF test.". This section of the ArchWiki gives a bit more detail on how one can do this, but I'm not aware of one or more lists of either
4.1. the valid option parameters for specifying non-default cryptographics (ciphers, hashes, keysizes, modes) to
cryptsetup benchmark. Can anyone point to definitive doc for this?
4.2. other, non-default cryptographics one should specify and benchmark, given current technologies and kernel support. Your suggestions appreciated (provided you also provide the appropriate option parameters :-)
- Are there "better" tools to use for LUKS performance pre-tuning than
cryptsetup benchmark? If so, what and how?
: e.g., https://wiki.archlinux.org/index.php/Dm-crypt/Device_Encryption#Encryption_options_for_LUKS_mode , https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata
info cryptsetup or
: see https://wiki.archlinux.org/index.php/Disk_encryption#Cryptographic_metadata