27

I'm looking for recommended options for cryptsetup to create fully encrypted SSD (SanDisk SSD U100 128GB), which achive:

Timing O_DIRECT disk reads: 1476 MB in  3.00 seconds = 491.81 MB/sec
Timing buffered disk reads: 1420 MB in  3.00 seconds = 473.01 MB/sec

My benchmark shows me best cipher:

# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       103696 iterations per second
PBKDF2-sha256      59904 iterations per second
PBKDF2-sha512      38235 iterations per second
PBKDF2-ripemd160   85111 iterations per second
PBKDF2-whirlpool   47216 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   133.2 MiB/s   432.0 MiB/s
 serpent-cbc   128b    18.1 MiB/s    67.3 MiB/s
 twofish-cbc   128b    39.3 MiB/s    73.0 MiB/s
     aes-cbc   256b    99.6 MiB/s   337.7 MiB/s
 serpent-cbc   256b    18.1 MiB/s    66.9 MiB/s
 twofish-cbc   256b    39.4 MiB/s    72.6 MiB/s
     aes-xts   256b   376.6 MiB/s   375.0 MiB/s
 serpent-xts   256b    69.0 MiB/s    66.5 MiB/s
 twofish-xts   256b    71.1 MiB/s    72.2 MiB/s
     aes-xts   512b   297.0 MiB/s   300.1 MiB/s
 serpent-xts   512b    69.6 MiB/s    66.6 MiB/s
 twofish-xts   512b    71.9 MiB/s    72.7 MiB/s

But perhaps, you could suggest some options, that would increase my performance and security. My CPU is: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz and it supports AES-NI (aes cpu flag).

Thank you

Artur Szymczak
  • 463
  • 1
  • 5
  • 8

2 Answers2

31

You might want to use PBKDF2 with SHA-512. This step is for converting your password into an encryption key (more or less directly). This is inherently open to offline dictionary attacks, and relates to the password hashing problematic. For that, you want to maximize the effort of the attacker by choosing an algorithm and iteration count which will make the task hardest for the attacker while keeping it tolerable for you; "tolerable" here depends on your patience, when you type the password at boot time.

Attackers will want to use some GPU and/or FPGA to speed up their attack, while you use a normal PC. Nowadays, normal PC are at ease with 64-bit arithmetic operations, and run SHA-512 about as fast as SHA-256; however, GPU much prefer 32-bit operations, and mapping them on FPGA is also easier than 64-bit operations. Therefore, by using SHA-512 instead of SHA-256, you give less an advantage to the attacker. Hence my recommendation: on modern hardware, for password hashing, prefer SHA-512 over SHA-256.

Remember to adjust the "iteration count" so that the time taken to process your password is at the threshold of the bearable: higher iteration counts mean longer processing time, but are proportionally better for security.

For actual encryption, you will want XTS, which has been designed to support disk encryption efficiently. This indeed shows in the benchmarks; this is for a SSD and you do not want the encryption to be much slower than the underlying hardware. Note that XTS splits the key into two halves, only one of which being used for the actual encryption. In other words, "aes-xts" with a 256-bit key actually uses 128 bits for the AES part. And that's good enough. There is no rational need for going to 256-bit keys -- i.e. 512-bit in the context of "aes-xts". 256-bit keys for AES imply some CPU overhead, which the benchmarks duly observe (300 MB/s vs 375 MB/s). With a SSD under the hood, you really want a fast encryption system, so do that.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Thank you. I've been looking for an answer like yours. *"Note that XTS splits the key into two halves, only one of which being used for the actual encryption. In other words, "aes-xts" with a 256-bit key actually uses 128 bits for the AES part."* -> Do you know any reference either in code or documentation that shows that it is the exactly what LUKS implements? I just really need to have it verified. Or is there a way where I could "visibly" be able to demonstrate this? (luksDump doesn't do much help.) Should I look for and rely on verbosity configurations in kernel? – konsolebox Jan 04 '15 at 17:02
  • @konsolebox See: [ArchWiki](https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode), [Wikipedia](https://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing_.28XTS.29). – Marc.2377 May 26 '17 at 23:35
  • 1
    I am a bit confused about `There is no rational need for going to 256-bit keys`. Does it mean when using `cryptsetup` to encrypt, specifying `--key-size=128` is enough that `--key-size=256` is unnecessary? – HCSF Feb 21 '21 at 14:29
  • @HCSF No aes-xts splits the key in half. If you specify `key-size 128` it will actually use 64-bit AES keys. You will want to specify `key-size 256` to use 128 bit keys for AES. – Maciej Krawczyk Dec 31 '21 at 15:49
  • Today cryptsetup default key-size is 512 (256 bit) for aes-xts. I'm not sure what is the reason for this but one thing I heard is that when quantum computers become viable, with some algorithm they can reduce aes key entropy to its square root - so 128 bit entropy would become 64 bit. So the military-grade standard today is 256 bit (which becomes 128-bit post-quantum). Do you need it for your personal computer? Probably not. 256 bit is still about 20% slower and the passphrase is the weakest link anyway (especially since LUKS does not support scrypt for hashing). – Maciej Krawczyk Dec 31 '21 at 16:00
7

Any combination of the above operation modes will provide you with ample security against most threats. That said, CBC is no longer recommended due to certain information leakage attacks. And SHA1 is depreciated in favour of the SHA2 family.

As always with crypto, stick with what is widely used and proven. So my overall recommendation would be: PBKDF2-sha256 aes-xts

lynks
  • 10,646
  • 5
  • 29
  • 54
  • 1
    Seconded, with a 256 bit AES key - 512 is overkill – Michael Aug 07 '13 at 12:00
  • 2
    @Michael, even if I'm a next Snowden? :) – Artur Szymczak Aug 07 '13 at 12:13
  • 1
    @ArturSzymczak - if you are Mr.Snowden, you already know all this and more. – Deer Hunter Aug 07 '13 at 12:15
  • @Artur, yes, even then. A 256 bit AES key is no where near the weakest link in your security setup. – Michael Aug 08 '13 at 06:19
  • 1
    System performance is important. If you can have 26% better performance with an equivalent security level, it's probably a good idea. There have also been [suggestions that AES-256 (used with a 512-byte XTS key) has weaknesses in the key schedule compared to AES-128](https://www.schneier.com/blog/archives/2009/07/another_new_aes.html). – GreenReaper May 08 '17 at 16:13