# Deciding on LUKS encryption algorithm

## impact0r

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. 
> ...

 

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:

```
# 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?

----------

## Hu

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.

----------

## impact0r

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?

----------

## Hu

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.

----------

## frostschutz

ware the crossposts http://unix.stackexchange.com/questions/107975/trying-to-understand-luks-encryption

----------

## m4chine

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?

```
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?

----------

## impact0r

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).

----------

## Hu

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.

----------

## m4chine

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.”

 

----------

## m4chine

impact0r, the point of all this is that you wont know if you are on the watch list until its too late  :Wink: 

----------

## impact0r

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.

----------

