LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 06-04-2019, 11:29 AM   #1
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Rep: Reputation: Disabled
LUKS Encryption is slow after moving disk to an older computer


When a LUKS partition is created on a machine with a fast CPU and the disk is transferred to an older computer with a slower CPU, the LUKS decryption time is annoyingly slow.

Is there a way to run cryptsetup on the faster machine such that when the disk is moved to the slower machine the decryption time remains at about 1 to 2 seconds?

Reason: We have an imaging system to prep hard drives. The imaging system is more modern and faster than our target systems. Many of the target systems are Core Duo or AM4. Old technology but nonetheless the older systems remain useful for their intended purpose.

My guess is the iteration algorithm used to impede brute force attacks is calibrated for the faster CPU. When the disk is moved to a slower CPU the iteration time remains the same but the slower CPU lacks the muscle to cycle the iterations as fast. Hence, much slower decryption times.

After moving the disk to the slow system the problem can be resolved using cryptsetup-reencrypt, but that requires a live ISO and the disk must be installed in the slower system. Would be much nicer if we could configure the encryption on the imaging station.

I have been tinkering but thus far have not found a solution other than cryptsetup-reencrypt.

Thanks again.
 
Old 06-04-2019, 05:40 PM   #2
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 18,144

Rep: Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935
More likely AES_instruction_set. If the hardware doesn't implement it, it would have to be emulated in software - ugh.
No simple solution I can think of.
 
Old 06-04-2019, 09:17 PM   #3
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 18,144

Rep: Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935Reputation: 2935
Thinking about this whilst walking the dog, maybe you should just recompile cryptsetup with a -mtune that excludes the AES instructions on the build machine.
strace should tell you if those instructions are being called.
 
Old 06-04-2019, 09:33 PM   #4
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 4,298

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
If the problem is just the time it takes to unlock, you should be able to simply add a key on the slower machine. The keyslot interation count will be calculated for the slow CPU. You will have to delete the keyslot built on the faster machine, or else ensure that the new keyslot has a lower slot number than the old so that the new one will be tried first.

You can also experiment with a reduced "--iter-time" option on the faster machine.

Last edited by rknichols; 06-04-2019 at 09:39 PM. Reason: Mention --iter-time
 
Old 06-05-2019, 12:23 PM   #5
upnort
Senior Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu
Posts: 1,212

Original Poster
Rep: Reputation: Disabled
Quote:
More likely AES_instruction_set. If the hardware doesn't implement it, it would have to be emulated in software - ugh.
That was my first thought too. Yet on the system where we saw the slow decryption time, I discovered the CPU supports the AES flag.

Quote:
recompile cryptsetup with a -mtune that excludes the AES
Interesting idea but too much work and the CPUs in question do support the AES flag.

Quote:
You can also experiment with a reduced "--iter-time" option on the faster machine.
This is the only option I am having some success.

The past two days I have been testing. My office system is a 2.7 GHz i5-6400 quad core. I configure the encryption on that system.

I test the encrypted disk on a 2.6 GHz AMD 5050e Dual Core. About a 10 to 20 times reduction in computing power.

With no options the decryption on the AMD takes about 12 seconds. I tinkered with --iter-time starting with 1000 milliseconds. Still too slow. My last effort was with 250 milliseconds, which resulted in a decryption time of about 1.5 seconds on the AM2.

I also am using --hash sha1.

I am aware of a general opinion that SHA1 is crackable susceptible to collision attacks. We do not need protection against alphabet soup gangs. We only need "good enough" encryption.

We use a 14-character password, containing mixed characters and numbers. Based on one equation I found, and presuming I understood correctly, the entropy is high. A brute force dictionary attack would take a long time even with the short iteration time.

Reading around the web indicates all discussions are based on encrypting on the same system where the disk will be used. I have not found any discussion about moving the disk and readjusting the encryption.

Perhaps --hash sha1 --iter-time 250 is the best I can do. There also remains the cryptsetup-reencrypt option. The latter is an extra clunky step but is doable.

Edit: Some quick testing indicates --hash sha256 does not affect the decryption time. --hash sha256 --iter-time 250 is now our default. Of course, my testing is limited to a single instance of one fast system and one slow system. Would be interesting to test with a variety of systems and SSDs too.

Last edited by upnort; 06-06-2019 at 10:21 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to have luks encryption with keyfile OR passphrase (efi full disk encryption including boot)? byroncollege Linux - Security 2 03-30-2017 07:45 AM
Mint 18 Full disk encryption VS Veracrypt Full Disk encryption: Help a Noob Decide Please ! APeacefulRig Linux - Security 2 11-11-2016 08:10 AM
Luks disk encryption balaji2219@gmail.com Linux - Newbie 2 08-06-2014 02:51 PM
Creating mdadm raid and luks disk encryption from the command line fakie_flip Linux - Software 1 01-07-2013 10:49 PM
How secure LUKS/LVM disk encryption really is? <Ol>Origy Linux - Security 14 03-09-2009 12:09 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 04:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration