View previous topic :: View next topic |
Author |
Message |
impact0r n00b
Joined: 24 Feb 2012 Posts: 63
|
Posted: Sat Jan 04, 2014 9:30 pm Post subject: Deciding on LUKS encryption algorithm |
|
|
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
1. First thing to decide on was the cipher. I am going to use SHA1 instead of 2/512 (as some suggest), because of that quote from cryptsetup FAQ:
Quote: | 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's no point of using anything other than SHA-1". If I got it wrong, please comment.
2. Now I need to choose 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:
Code: | # 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 not only is the fastest, but on top of that it is the fastest with the most complex key!
Shouldn't it be the other way around? Do I read it wrong, or something? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Sat Jan 04, 2014 9:50 pm Post subject: |
|
|
I think you slightly misunderstand point 1. While it is true that the ability to force sha1 collisions is not a threat to the security of LUKS, it is not true that there is no value in using some other key derivation function. As I understand it, LUKS uses the hash function to convert your passphrase into a slot key. Slot keys are used to protect the master key. So if someone can divine the slot key, they can unlock the master key, even if they have no idea what passphrase generated their divined slot key. Different key derivation functions have different characteristics with regard to both bit mixing and time required to perform N iterations. All else being equal, the slowest hash function you can stand is theoretically best, since it means the greatest cost to an attacker who hashes every possible input looking for one that generates a valid slot key. On the other hand, LUKS developers probably picked defaults that make iterated use of sha1 slow enough in this case to make an attacker's life hard. Also, this discussion applies only if you assume the existence of an attacker who will try to determine the passphrase through bruteforce. If the attacker tries a limited number of "obvious" passphrases and then quits on failure, you could use a very weak hash and still be safe. |
|
Back to top |
|
|
impact0r n00b
Joined: 24 Feb 2012 Posts: 63
|
Posted: Sat Jan 04, 2014 10:24 pm Post subject: |
|
|
If
“LUKS uses the hash function to convert your passphrase into a slot key”
and
“if someone can divine the slot key, they can unlock the master key, even if they have no idea what passphrase generated their divined slot key.”
then how can they not know they passphrase, if the cipher that the cracked hashed the passphrase, which is necessary to access the master key?
I think my ignorance is partially caused by not understanding your use of word “divine”.
Also, does the hash used have any impact on disk read/write performance during normal system use, like an algorithm does?
Any comments on point 2? |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Sun Jan 05, 2014 12:08 am Post subject: |
|
|
Barring some bug in the LUKS tools, an attacker would not be in a position to divine the slot key other than by observing the entry of the passphrase that creates it. I remarked on that point because hash functions are designed to be one way, so an attacker who knows the slot key is not guaranteed to know the passphrase. However, since the slot key guards the master key, you get no real protection from this distinction.
"Divine" - to gain knowledge of, often through means that can be considered magical for the purpose of the immediate discussion. In this case, an attacker who divined the slot key would be one who learnt it through some means other than learning the passphrase and applying the key derivation function to the passphrase.
I think the hash ought not have an effect on disk throughput. The encryption is done by the kernel using the volume key. The hash is required to derive the key that permits you to decrypt the volume key. As far as I know, the hash is not used once the volume key has been loaded into the kernel.
No comment on point 2. |
|
Back to top |
|
|
frostschutz Advocate
Joined: 22 Feb 2005 Posts: 2977 Location: Germany
|
|
Back to top |
|
|
m4chine Apprentice
Joined: 12 Mar 2003 Posts: 271 Location: Ventura, CA, USA
|
Posted: Thu Feb 20, 2014 5:48 pm Post subject: |
|
|
So what is the general consensus for encryption and hashing? I've been trying to decide on what to use myself. I am more security conscious that performance conscious at this time. I am looking at using the serpent cipher and sha256 hashing. Any objections there with the recent NSA revelations?
Code: | cryptsetup -v --cipher serpent-xts-plain64 --key-size 1024 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sd{device} |
And with XTS, the key is basically split in two parts, so using a keysize of 1024 effectively uses 512. Is that a large enough key? Or should I use something larger, 2048? _________________ never trust a man who can count to 1023 on his fingers.
-m4chine |
|
Back to top |
|
|
impact0r n00b
Joined: 24 Feb 2012 Posts: 63
|
Posted: Thu Feb 20, 2014 6:08 pm Post subject: |
|
|
Here's what I learned from dm-crypt creators:
1. sha256 offers absolutely no benefit over sha1 for the purpose of disk encryption. However, hash used has no impact on disk performance.
2. If you are not on the NSA watchlist, I would not bother with anything over xts 256, unless the performance is the same (as it was for me for serpent 256 and 512 - but I went for 256 anyway). |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Thu Feb 20, 2014 11:10 pm Post subject: |
|
|
Remember that disk encryption only protects you if an adversary obtains access to the disk while the volume is locked. If you are cracked over the Internet, then your filesystem is already unlocked and can be browsed as readily as if it were plain text. |
|
Back to top |
|
|
m4chine Apprentice
Joined: 12 Mar 2003 Posts: 271 Location: Ventura, CA, USA
|
Posted: Fri Feb 21, 2014 6:03 pm Post subject: |
|
|
Understood. I just wanted to ensure I was not using encryption/hashing algorithms utilized by Dual_EC_DRBG and the PRNG that is thought to be backdoored by the NSA.
Quote: | “Recommending against the use of SP 800-90A Dual Elliptic Curve Deterministic Random Bit Generation: NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used.” |
_________________ never trust a man who can count to 1023 on his fingers.
-m4chine |
|
Back to top |
|
|
m4chine Apprentice
Joined: 12 Mar 2003 Posts: 271 Location: Ventura, CA, USA
|
Posted: Fri Feb 21, 2014 6:07 pm Post subject: |
|
|
impact0r, the point of all this is that you wont know if you are on the watch list until its too late _________________ never trust a man who can count to 1023 on his fingers.
-m4chine |
|
Back to top |
|
|
impact0r n00b
Joined: 24 Feb 2012 Posts: 63
|
Posted: Fri Feb 21, 2014 6:23 pm Post subject: |
|
|
Well, apart from logical axiomats, you don't know anything for sure.
The question is: is it reasonable to think you are, and to obstruct your computer experience because of that belief?
For me - it is not. |
|
Back to top |
|
|
|