LUKS Encryption
Recently I poked around trying to learn how to keep the LUKS passphrase response to about 1 second — based on the target system CPU that will use the disk rather than the CPU in which the disk is prepared.
Based on using different CPUs, I noticed cryptsetup determines the hash spec and number of iterations based on the host CPU.
At work we have an imaging station where we prepare disks for use in other systems. We remove the disk from a system and prep the disk in the imaging system. For laptops the prep includes encrypting the system partition with LUKS. We then return the disk to the original system.
Nothing fancy:
cryptsetup -y -v luksFormat $DISK_PARTITION
The CPU of the imaging system affects the LUKS pass phrase encryption.
When I first started tinkering with LUKS I used my personal office system with a 4-core i5. Later at work the imaging system became an AM2 dual core.
LUKS partitions created with the i5 were formatted with sha256 and high iterations. LUKS partitions created with the AM2 were formatted with sha1 and fewer iterations.
We need to format the LUKS partitions based on the final target system and not the host system.
The target systems are old, most of which are first or second generation dual cores. Not a lot of CPU muscle with respect to modern systems, but they serve our purpose.
One of our work laptops (AMD A4-5000) using LUKS was formatted on the i5. When the disk was returned to the laptop after imaging, the result is a very slow response time to typing the pass phrase. I understand why — the original formatting was performed on a more powerful system and is now decrypting on a less powerful CPU.
I can use cryptsetup-reencrypt to fix the slow response time.
Our goal is not to encrypt based on the host system but based on the final target system. For now the following change seems to help:
cryptsetup -y -v --hash sha1 --iter-time=500 luksFormat $DISK_PARTITION
Our other LUKS encrypted systems are older dual core systems. When we imaged the new disks on the AM2 dual core system, the iteration times are about 1 second when we restore the disk to the older system. If the imaging system is more powerful, such as a 4-core i5, moving the new disk to the older system results in a much longer iteration time because the original formatting was done on a more powerful system.
While SHA1 is susceptible to collision attacks with a supercomputer and a year of time, my understanding is LUKS is not affected. 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 understand correctly, the entropy is high. A brute force dictionary attack would take a long time even with the short iteration time.
Posted: Category: Usability Tagged: General
Next: Nightly Shutdowns
Previous: Boot Failure and _netdev