Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Deciding on LUKS encryption algorithm
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
impact0r
n00b
n00b


Joined: 24 Feb 2012
Posts: 63

PostPosted: Sat Jan 04, 2014 9:30 pm    Post subject: Deciding on LUKS encryption algorithm Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13855

PostPosted: Sat Jan 04, 2014 9:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
impact0r
n00b
n00b


Joined: 24 Feb 2012
Posts: 63

PostPosted: Sat Jan 04, 2014 10:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13855

PostPosted: Sun Jan 05, 2014 12:08 am    Post subject: Reply with quote

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
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2970
Location: Germany

PostPosted: Sun Jan 05, 2014 7:52 pm    Post subject: Reply with quote

ware the crossposts http://unix.stackexchange.com/questions/107975/trying-to-understand-luks-encryption
Back to top
View user's profile Send private message
m4chine
Apprentice
Apprentice


Joined: 12 Mar 2003
Posts: 271
Location: Ventura, CA, USA

PostPosted: Thu Feb 20, 2014 5:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
impact0r
n00b
n00b


Joined: 24 Feb 2012
Posts: 63

PostPosted: Thu Feb 20, 2014 6:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 13855

PostPosted: Thu Feb 20, 2014 11:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
m4chine
Apprentice
Apprentice


Joined: 12 Mar 2003
Posts: 271
Location: Ventura, CA, USA

PostPosted: Fri Feb 21, 2014 6:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
m4chine
Apprentice
Apprentice


Joined: 12 Mar 2003
Posts: 271
Location: Ventura, CA, USA

PostPosted: Fri Feb 21, 2014 6:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
impact0r
n00b
n00b


Joined: 24 Feb 2012
Posts: 63

PostPosted: Fri Feb 21, 2014 6:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum