# Moving encrypted file storage/changing cipher options

## abduct

Way back when I created a cryptsetup luksFormat encryption partition, although I used blowfish as my cipher, and whirlpool as my hash.

Is there a simple way to change my cipher/hash combo on existing created encryption partitions? Or am I stuck copying all the data in an unencrypted state to a storage drive, deleting and remaking the partition with the proper cipher I wish to use now, and then transferring the data back. I may also be able to move the encrypted file partition to a external hard drive to mount via luksOpen and /dev/mapper like I do now, allowing me to erase the existing ones and transferring the files to the new AES partition.

Is it even worth me making the move to AES or another cipher such as twofish/serpent, or is blowfish still quite secure except for it getting on in age. Likewise with whirlpool hashes.

Thanks for any information!

----------

## frostschutz

There is cryptsetup-reencrypt (reencrypt useflag) but as always, doing such operations in-place has risks. If anything goes wrong you're in a mess. So at the very least you should have backups, of both data and LUKS header just in case... if all you wish to change is the hash you can probably use the --keep-key option of reencrypt.

```
Is it even worth me making the move to AES
```

Use 'cryptsetup benchmark' to find out. If your CPU supports AES-NI it makes a huge difference, the other ciphers can't compare performance-wise.

The security of the hash matters little, the hash is randomized in any case (salt) and its main use is wasting CPU cycles (by iterating for as many times as possible within 1 second, so verifying any passphrase takes that long - on your machine). It slows down bruteforce attempts, which is nice but a good/long passphrase is even more important.

For the hash, the library you use also makes a difference: http://www.metamorpher.de/files/cryptsetup-benchmark.html

----------

## abduct

Thanks for the reply, I have a fairly recent processor (i5-3317U) which supports "AES New Instructions", although when I ran `cryptsetup benchmark` it does not list ciphers only hashes. It does tell me that the "kernel crypto interface is not available" and that I should ensure algif_skcipher kernel module is loaded. I've tried to modprobe -a that kernel module name, but it continues giving me the error. I've also tried reloading dm_mod and dm_crypt to no avail. It's weird why it would be failing if it's decrypting everything fine at boot. I'll have a peak in my kernel config and see if I forgot to compile it in.

Anyways the results show that sha1 is the fastest performing on my computer followed by ripemd160, with whirlpool in last place. Would it be wise to change to the better performing hash?

Thanks for your reply.

Edit:: Booted into the systemrescue cd and ran the bencmarks

AES is indeed faster but which version should I use? AES-xts 256b offers the best performance (1260mib/s, 125Mib/s) although should I go for the larger 512b key version which is slightly slower (1010mib/s, 963mib/s)  (but many times faster than all the other algos?)

If I wanted the optimal setup would I choose sha1 (255003 iterations/s) or ripemd160 (201030 iterations/s) and AES-XTS 512 or 256?

Thanks.

----------

## frostschutz

 *abduct wrote:*   

> when I ran `cryptsetup benchmark` it does not list ciphers only hashes.

 

find /lib/modules -iname "*aes*" (for aesni you're looking for some aesni-intel module or similar)

or maybe the crypto stuff is not enabled in your kernel in general

 *Quote:*   

> 
> 
> Anyways the results show that sha1 is the fastest performing on my computer followed by ripemd160, with whirlpool in last place. Would it be wise to change to the better performing hash?
> 
> 

 

Slow is OK. Hashes are supposed to waste CPU cycles, so they're called thousands of times in iteration. (It's only used on luksOpen and should take about a second to check the password, so bruteforcers can't try millions-of-passwords-per-second). I went with sha512, but it makes little difference in practice.

Your AES speeds sound weird to me, probably aesni was not loaded first...?

Check that your CPU actually does have it: grep aes /proc/cpuinfo

Some systems disable it (laptops etc.) even though the CPU would be capable of it

The default cipher is aes-xts-plain64 with 256bit keys; you can go with 512bit instead, if the speeds are fine for you (which they might be with aesni). But even 256b is secure so ... pick your poison

----------

## abduct

 *Quote:*   

> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
> 
> 

 

I didn't see a aesni flag in there, but there is a aes flag present. Is there a way to enable it? Is it a kernel option I have to enable?

Are the AES speeds supposed to be greater than what they are now? The benchmark shows that AES is 5 times faster than serpent and twofish so I think I am going to make the switch anyways. After all blowfish would probably be around the same speed as twofish or slightly slower I would imagine.

Thanks again for the help.

----------

## schorsch_76

 *abduct wrote:*   

> 
> 
> Is it even worth me making the move to AES or another cipher such as twofish/serpent, or is blowfish still quite secure except for it getting on in age. Likewise with whirlpool hashes.
> 
> Thanks for any information!

 

Because a cipher is quite "old", id does not mean, it is bad. Take a look and/or ear at [1][2][3][4]. It will enlighten your mind!

[1] Applied Cryptography from Bruce Schneier

[2] https://www.youtube.com/watch?v=1dhCDJ_LVuY (german)

[3] https://www.youtube.com/watch?v=MjAhrsCJqgg (german)

[4] https://www.youtube.com/watch?v=HJB1mYEZPPA (english: This year in crypto with DJB (THE crypto expert) ,Tanja Lange and Nadja Heninger)

In general, when you don't trust, your cipher, reencrypt with a new cipher you trust.

EDIT: When you just have time to watch one, i really recommend [4] !!!

----------

## frostschutz

aes cpu flag is fine

Your benchmark is weird, for me AES encryption/decryption speeds are about the same (see my benchmark link above - it's a Haswell i5-4570)

----------

## Roman_Gruber

you may consider

lvm container

luks container

filesystem like ext4

than you could at least move your data junks.

----------

## kernelOfTruth

 *frostschutz wrote:*   

> There is cryptsetup-reencrypt (reencrypt useflag) but as always, doing such operations in-place has risks. If anything goes wrong you're in a mess. So at the very least you should have backups, of both data and LUKS header just in case... if all you wish to change is the hash you can probably use the --keep-key option of reencrypt.
> 
> 

 

++

 *frostschutz wrote:*   

> 
> 
>  *abduct wrote:*   Is it even worth me making the move to AES 
> 
> Use 'cryptsetup benchmark' to find out. If your CPU supports AES-NI it makes a huge difference, the other ciphers can't compare performance-wise.
> ...

 

++

Also make sure to compile in the support for the SSSE3 (mark the 3 (!) S) accelerators and CONFIG_CRYPTO_PCRYPT

```
zgrep SSE3 /proc/config.gz

CONFIG_CRYPTO_SHA1_SSSE3=y

CONFIG_CRYPTO_SHA256_SSSE3=y

CONFIG_CRYPTO_SHA512_SSSE3=y
```

 *frostschutz wrote:*   

> 
> 
> The security of the hash matters little, the hash is randomized in any case (salt) and its main use is wasting CPU cycles (by iterating for as many times as possible within 1 second, so verifying any passphrase takes that long - on your machine). It slows down bruteforce attempts, which is nice but a good/long passphrase is even more important.
> 
> For the hash, the library you use also makes a difference: http://www.metamorpher.de/files/cryptsetup-benchmark.html

 

Now THAT's impressive   :Exclamation:   :Shocked: 

Seems like I'll need to re-do my volumes in the near future

Thanks   :Smile: 

----------

## kernelOfTruth

Luckily I found this out before actually attempting (in vain) to boot and open up the volumes

nettle does NOT support whirlpool hash:

 *Quote:*   

> cryptsetup luksOpen /dev/foo tank
> 
> Requested LUKS hash whirlpool is not supported. 

 

In that case I'm reverting back to tested (and working) openssl-backend   :Arrow: 

----------

