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

2 Answers 2


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?
    – konsolebox
    Commented Jan 4, 2015 at 17:02
  • @konsolebox See: ArchWiki, Wikipedia.
    – Marc.2377
    Commented May 26, 2017 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
    Commented Feb 21, 2021 at 14:29
  • So, the key sizes shown by cryptsetup benchmark for aes-xts, are they the sizes given on the command line, or the halves of them, that are actually used?
    – Alexey
    Commented Jul 24, 2023 at 12:54

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


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .