8

I decided to encrypt my root partition with LUKS+LVM.

My ThinkPad setup:

  • Samsung 830 128GB SSD
  • 750GB HDD
  • Core 2 Duo 2,5 GHz P9500
  • 8GB RAM

But the more I read, the less I understand about those two following subjects:

1a. The cipher

I was going to use SHA1 instead of 2/512 (as some suggest), because of that quote from cryptsetup FAQ:

5.20 LUKS is broken! It uses SHA-1!

No, it is not. SHA-1 is (academically) broken for finding collisions, but not for using it in a key-derivation function. And that collision vulnerability is for non-iterated use only. And you need the hash-value in verbatim.

This basically means that if you already have a slot-key, and you have set the PBKDF2 iteration count to 1 (it is > 10'000 normally), you could (maybe) derive a different passphrase that gives you the the same slot-key. But if you have the slot-key, you can already unlock the key-slot and get the master key, breaking everything. So basically, this SHA-1 vulnerability allows you to open a LUKS container with high effort when you already have it open.

The real problem here is people that do not understand crypto and claim things are broken just because some mechanism is used that has been broken for a specific different use. The way the mechanism is used matters very much. A hash that is broken for one use can be completely secure for other uses and here it is.

Which I read as "there is no point of using anything other than SHA-1". But then some people tell me, that it's not exactly like that. So I no longer know what to think.

1b.

Also, I could not find any information whether the cipher has any influence on disk read/write/seek performance once the disk is unlocked and system logged into.

So does the complexity of the cipher affect only the "performance" on password entering stage, or also during normal use of the system?

2. The algorithm

I have been reading on this since couple of days, but the more I read, the more confused I get. Everything I read says that AES is the fastest, and Serpent is the slowest. But not according to my laptop:

$ cryptsetup benchmark
Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       344926 iterations per second
PBKDF2-sha256     198593 iterations per second
PBKDF2-sha512     129007 iterations per second
PBKDF2-ripemd160  271933 iterations per second
PBKDF2-whirlpool  134295 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   149.8 MiB/s   147.9 MiB/s
 serpent-cbc   128b    51.0 MiB/s   196.4 MiB/s
 twofish-cbc   128b   127.6 MiB/s   152.5 MiB/s
     aes-cbc   256b   114.3 MiB/s   113.8 MiB/s
 serpent-cbc   256b    51.2 MiB/s   198.9 MiB/s
 twofish-cbc   256b   129.8 MiB/s   167.5 MiB/s
     aes-xts   256b   153.3 MiB/s   150.6 MiB/s
 serpent-xts   256b   176.4 MiB/s   184.1 MiB/s
 twofish-xts   256b   160.8 MiB/s   159.8 MiB/s
     aes-xts   512b   115.4 MiB/s   112.1 MiB/s
 serpent-xts   512b   178.6 MiB/s   184.2 MiB/s
 twofish-xts   512b   160.7 MiB/s   158.9 MiB/s

So it appears that Serpent's not only the fastest, but on top of that it is the fastest with the most complex key.

Shouldn't it be the other way around? Am I reading it wrong, or something?

1
  • So why not using SHA512 for more security if it hashes anyway to 1 sec real time.
    – user284148
    Jan 15, 2015 at 13:48

1 Answer 1

Reset to default
5

1a - it really doesn't matter all that much. which ever hash you use for the key derivation function, LUKS makes sure it will be computationally expensive. It will simply loop it until 1 second real time has passed.

1b - the key derivation method has no influence on performance. the cipher itself does. cryptsetup benchmark shows you as much.

2 - AES is the fastest if your CPU is modern enough to support AES-NI instructions (hardware acceleration for AES). If you go with serpent now you may not be able to utilize the AES-NI of your next laptop.

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1165084 iterations per second
PBKDF2-sha256     781353 iterations per second
PBKDF2-sha512     588426 iterations per second
PBKDF2-ripemd160  726160 iterations per second
PBKDF2-whirlpool  261882 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   692.9 MiB/s  3091.3 MiB/s
 serpent-cbc   128b    94.6 MiB/s   308.6 MiB/s
 twofish-cbc   128b   195.2 MiB/s   378.7 MiB/s
     aes-cbc   256b   519.5 MiB/s  2374.0 MiB/s
 serpent-cbc   256b    96.5 MiB/s   311.3 MiB/s
 twofish-cbc   256b   197.9 MiB/s   378.0 MiB/s
     aes-xts   256b  2630.6 MiB/s  2714.8 MiB/s
 serpent-xts   256b   310.4 MiB/s   303.8 MiB/s
 twofish-xts   256b   367.4 MiB/s   376.6 MiB/s
     aes-xts   512b  2048.6 MiB/s  2076.1 MiB/s
 serpent-xts   512b   317.0 MiB/s   304.2 MiB/s
 twofish-xts   512b   368.7 MiB/s   377.0 MiB/s

Keep in mind this benchmark does not use storage so you should verify these results with whatever storage and filesystem you are actually going to use.

1
  • 1
    1. Thanks for clarifying. So I can go ahead and use SHA512 without any negative effect on disk performance. 2. I find it strange that according to Intel's website ( ark.intel.com/search/advanced/?s=t&AESTech=true ) old Pentiums had this optimisation, but C2Ds don't. "If you go with serpent now you may not be able to utilize the AES-NI of your next laptop." By that I understand you meant I would have to recrypt the disk into AES. Right? The benchmark tells me of CPU performance. My SSD is on SataII 3.0 Gbps (200-280MB/s), so I guess I won't do any better than serpent-xts 512b
    – lockheed
    Jan 5, 2014 at 22:08

You must log in to answer this question.

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