LUKS performance

Overview

LUKS encryption scheme is based on AES-256 algorithm. AES, or more precisely Rijndael, was chosen because it combines expected security level with very good encryption and decryption performance. Since it is relatively easy to implement, several hardware acceleration solutions were made, including AES-NI extension for most modern CPUs.

Drive Badger uses LUKS encryption to protect exfiltrated data, stored on Kali Linux Persistent partition, from being accessed by any third party person (see Emergency procedure for more details).

LUKS vs no encryption - performance comparison

On AES-NI-compatible CPUs, LUKS encryption costs more intensive CPU usage (which can be visible, especially if the computer works in graphical mode, or runs other CPU-intensive applications), but shouldn't slow down I/O processes.

Just to make sure, we performed some real tests:

• Core 2 Duo E8400, 4GB RAM (standard Dell OptiPlex 780, built in 2010)
• copying from Samsung SSD 850 EVO 500GB
• copying to Samsung Portable SSD T5 1TB USB 3.1, connected to USB 2.0 port (with UASP enabled)
• set of files - as for typical Windows C++ developer:
  • Windows 10 Home
  • Visual Studio with many additional tools
  • Embarcadero RAD Studio
  • total 27GB of data in ~134000 files (after applying rsync exclusion rules)

We compared 2 variants: in the first one, both drives were not encrypted. In the second, target drive (T5) was LUKS-encrypted (aes-xts-plain64 with a 512-bit key, sha512 hashing algorithm and PBKDF2 processing time increased to 5 seconds - these are exactly the same parameters, as we suggest in our security advice).

Average results (lower time is better):

1. No encryption - 14m 5s.
2. LUKS encryption - 14m 2s. However CPU usage and system load were noticeably bigger.

You can see more interesting benchmarks here.

Problematic hardware

LUKS encryption requires working crng random number generation subsystem. On most hardware, even very old, it works without any problems. However we identified some specific hardware platforms, that prevent crng from running properly: crash the host during boot, or simply allow entropy gathering too late to allow decryption of Kali Linux Persistent partition.

Kali Linux, depending on chosen version and BIOS/UEFI settings, can boot either in graphical or text mode. In general, if it's able to run in graphical mode, it should be also able to properly handle LUKS partition. If it boots in text mode, then you should find similar message somewhere before asking for LUKS password:

random: crng init done

On problematic hardware, you will instead see:

uninitialized urandom read (4 bytes read)

And then trying to enter password (no matter if valid or not) will always result in similar error:

Please unlock disk /dev/sda3:*****************************
There was an error decrypting /dev/sda3 ... Retry (Y/n)
Not enough available memory to open a keyslot.

There is no solution for that - to exfiltrate data in such cases you need to use another drive, with unencrypted persistent partition. But remember to use it only as a last-chance drive.

List of hardware found problematic:

1. Acer Aspire One D270
2. Asus Eee Box B202
3. Dell OptiPlex FX160 (possibly also FX170)
4. Fit-PC2 by CompuLab
5. HP ThinClient T5740 (affects only older firmware "T5000 series")