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 is not a `cryptsetup` FAQ[1].)
details:
I'm about to reinstall OS on a 2007-ish laptop (with 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" per its manpage.
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-sha512 256000 iterations per second
PBKDF2-ripemd160 336082 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
ISTM that, in the above results,
1. encryption: serpent-xts/512 is fastest, serpent-xts/256 is a very close 2nd, serpent-cbc/* is slowest
2. decryption: serpent-cbc/256 is fastest, serpent-xts/512 is 3rd fastest, serpent-xts/256 is a very close 4th
3. key derivation: sha1 is significantly faster than sha256 is significantly faster than sha512
4. (meta) sha1 is too insecure and should not be considered.
Am I missing something? Presuming not, 'serpent-xts/512' seems the best compromise for both de- and encryption. But for key derivation, length(key)==256 seems significantly faster than length(key)==512: |356173 - 256000| / ((356173 + 256000)/2) ~= 0.327
So a specific question is:
1. Should I give more weight to the significant speed advantage of sha256 in key derivation, 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:
2. 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 have no clue when key derivation is done.
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 wanna 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:
3. Can one generally rank importance of speed of key derivation, decryption, and encryption? (I'm guessing the answer is "no" but ICBW.)
4. I know that default, no-argument runs of `cryptsetup benchmark` "[measures only a] few common configurations" (per its manpage). Are there other {ciphers, hashes, key sizes} one should specify and benchmark, given current technologies and kernel support?
5. Are there "better" tools to use for LUKS performance pre-tuning than `cryptsetup benchmark`? If so, what and how?
TIA, Tom Roche
[1]: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss