1

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.

Mars
  • 1,853
  • 3
  • 15
  • 22

2 Answers2

1

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.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 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 05: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. – Gilles 'SO- stop being evil' Jul 20 '16 at 07:33
0

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

Alexey Vesnin
  • 1,565
  • 1
  • 8
  • 11
  • 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 – Alexey Vesnin 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. – Gilles 'SO- stop being evil' Jul 18 '16 at 23:01
  • @Gilles Oh, really? https://www.researchgate.net/publication/220793242_AES-512_512-Bit_Advanced_Encryption_Standard_algorithm_design_and_evaluation – Alexey Vesnin 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.) – Gilles 'SO- stop being evil' Jul 18 '16 at 23:29
  • @Gilles there's **no AES algorythm exists**, actually. AES = Advanced Encryption Standard. An AES-standart contest winner was a Rijndael aglorythm, so... Let's speak correctly: YES, there's no AES-512 *standardized algorythm*, but there're Rijndael 512bit key implementations that *do exist* and work perfectly fine. – Alexey Vesnin Jul 18 '16 at 23:33
  • @AlexeyVesnin Nonsense. There's a family of three block ciphers, called AES-128, AES-192 and AES-256. This family is collectively known as AES. They are three instances among many of the Rijndael family. – Gilles 'SO- stop being evil' Jul 18 '16 at 23:41
  • @Gilles On the contrary - please read [Wikipedia](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process) and [NIST CSRC](http://csrc.nist.gov/archive/aes/) and take a deeper look – Alexey Vesnin Jul 19 '16 at 20:24