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).
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:
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):
You can see more interesting benchmarks here.
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.