Recommended options for LUKS (cryptsetup)
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.80GHzand it supports AES-NI (
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.
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?