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 <em>pre-</em>tuning
than `cryptsetup benchmark`? If so, what and how?
TIA, Tom Roche <[email protected]>
[1]: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
---------------------------------------------------
PLUG-discuss mailing list - [email protected]
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
