I want to have an encrypted partition on my SSD.

Benchmarks (a 100 samples of 100MiB each):
Average read speeds: 418 MB/s
Average write speeds: 386 MB/s

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       484554 iterations per second for 256-bit key
PBKDF2-sha256     666185 iterations per second for 256-bit key
PBKDF2-sha512     459096 iterations per second for 256-bit key
PBKDF2-ripemd160  297552 iterations per second for 256-bit key
PBKDF2-whirlpool  204161 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   535.0 MiB/s  1903.7 MiB/s
 serpent-cbc   128b    75.2 MiB/s   264.3 MiB/s
 twofish-cbc   128b   165.7 MiB/s   311.6 MiB/s
     aes-cbc   256b   392.5 MiB/s  1433.2 MiB/s
 serpent-cbc   256b    75.2 MiB/s   265.2 MiB/s
 twofish-cbc   256b   165.4 MiB/s   312.8 MiB/s
     aes-xts   256b  1592.4 MiB/s  1583.7 MiB/s
 serpent-xts   256b   271.9 MiB/s   260.4 MiB/s
 twofish-xts   256b   306.6 MiB/s   307.5 MiB/s
     aes-xts   512b  1218.7 MiB/s  1241.1 MiB/s
 serpent-xts   512b   272.0 MiB/s   258.8 MiB/s
 twofish-xts   512b   306.1 MiB/s   306.4 MiB/s

I don't really know how to interpret this. I see that an obvious choice is AES-XTS, but which one? i.e. how is it possible that AES-XTS can read and write faster than my actual read/write speeds?! Does it matter at this point if I choose AES-XTS 512 VS 256? Or can they both give me the maximum read/write speeds of my drive?

What about hashing? Why is PBKDF2-SHA1 slower than PBKDF2-SHA2? And how many iterations should I choose if I chose PBKDF2-SHA512? (I don't mind waiting for up to 3-5 seconds.


AES, Serpent and Twofish are block ciphers, i.e. the basic building blocks of some cryptosystems relying on symmetric keys. AES is the standard, and there's no reason to pick anything else. All three are secure but AES has received more scrutiny to it may be considered safer. AES has better performance if your machine has hardware acceleration for it, which is the case of most high-end machines and many midrange Intel processors.

For the key size, 128 bits is fine for almost all use cases. (It's considered risky only if you want your data to resist for more than a decade.)

CBC and XTS are two block cipher mode. A mode of operation describes how the block cipher primitive is applied to data. Both CBC and XTS are fine from a security point of view. The difference is that CBC only provides confidentiality, whereas XTS provides both confidentiality and integrity. If you're only concerned about someone decrypting your data, CBC is good enough. With XTS, you'll know if someone (or something) corrupts the data on your disk: you'll get an error message instead of garbage data. Integrity verification is only useful if someone can modify your data, but you still trust the hardware afterwards, which is rarely the case. With XTS, there are two keys, which is why the key size figures are double those for CBC. aes-xts 256b uses two AES-128 keys, etc.

Finally PBKDF2 is a key stretching function, i.e. a way to compute a key from a password that slows down brute-force attempts. The second part is a hash function. PBKDF2 is actually a famility of key stretching functions: each choice of hash defines a choice of PBKDF2 mode. Here, all choices are ok, but SHA-1 is deprecated. Pick SHA-256 or SHA-512: they're the standard choice. Performance-wise, SHA-256 has a slight edge on 32-bit machines, SHA-512 on 64-bit machines. SHA-1 is deprecated (though not yet known to be broken, especially for in a key stretching context). SHA-256 or SHA-512 are fine.

Summary: pick PBKDF2-sha256 and aes-cbc unless you have a good reason.

  • How many iterations do I choose for Key Stretching? I actually use the time parameter in my current setup and it came out to be done some 1 million and a half times of iteration. It's an OK time to wait in my PC, but if I plug this into lower end PCs, do I expect a LONG wait time? (And by long I mean more than 10 seconds)
    – Mars
    Jul 20 '16 at 5:09
  • @Mars Iteration count is a compromise between how long you're prepared to wait and how long you're making the attacker wait. I recommend that you do use --iter-time and choose an acceptable time. Yes, the time is machine-dependent so if you do the key creation on a fast machine and then mount on a slow machine you'll have to wait longer. I can't tell you how many times longer, it depends too much on the relative performance of the machines. If you have a strong passphrase (meaning sufficient entropy in the random generation process) then a high iteration count is not essential. Jul 20 '16 at 7:33

First, key length ("512 vs 256") is truly up to the importance of data protected, but - IMHO - if it is so important that it will require a 512 key, a disk encryption all by itself is not enough to protect that kind of data. And - unless you have a hardware-accelerated AES512 - I strongly recommend you to use 256 bit to reduce disk encryption payload: AES up to 256 inclusive is hardware-accelerated by most of CPUs nowdays, like Intel CPUs

Second, hashing with SHA256 or SHA512 is just fine, don't use a SHA1 due to it's weakness(supposed). SHA256 and 512 are frequently backed up by CPU instructions as well too, especially SHA256, for example by Intel CPUs.

So - briefly - use AES256 and SHA256 for disk encryption

  • Consider that XTS will actually use half the key size, twice. So 256bit key will actually need AES-XTS 512 (there's no AES512 to begin with in the original Rijndael paper as far as I know). But still, this didn't answer my questions. Thanks for your time, though.
    – Mars
    Jul 18 '16 at 17:55
  • @Mars Actually, take a look at the AES NI whitepaper I've linked and the Rijndael paper - there's no "upper limit" for key size, it's only a number of rounds, roughly. There are some implementations of true AES512 in existence and they works: I know software implementations, a hardware implementation, actually, is not so complicated using, for example, a Xilinx Spartan FPGA. I propose AES256-cbc + PBKDF2-sha256 hashing in your particular case Jul 18 '16 at 18:00
  • XTS uses two keys. AES-XTS 512 uses two AES-256 keys. There is no 512-bit key size for AES. AES-XTS 512 is not built on a non-standard Rijndael variant with a 512-bit key, it's built on the standard AES-256, with one key for confidentiality and one for authentication. Jul 18 '16 at 23:01
  • @Gilles Oh, really? researchgate.net/publication/… Jul 18 '16 at 23:24
  • @AlexeyVesnin That paper proposes, as the abstract clearly states, a new algorithm that the authors call AES-512. (It won't be compatible with someone else's AES-512 if they don't pick the same number of rounds.) This illustrates that there is no standard AES-512. (AES-256 is already overkill in most circumstances; AES-512 would only be useful in some extremely specific use cases with partial side channels, which is why it hasn't been standardized.) Jul 18 '16 at 23:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.