Opening TRESOR without TRESOR 23. April 2012
I spent the last few hours toying around with TRESOR, a fairly new approach to encrypt disks in Linux without storing the key in RAM, thus avoiding cold boot attacks and the like.
After an initial benchmark test of how bad the performance gets (not much worse than with LUKS and AES. That is, on an AES-NI-capable Core i5), I started thinking about disaster recovery: What if my
/boot partition dies or anything else happens that prevents me from booting a TRESOR-capable kernel. How am I going to access my data without compiling another kernel?
The way you open the encrypted device is just the same as for normal dm-crypt devices, with cryptsetup. Only the
--cipher tresor option you pass it is special about TRESOR devices. So I started digging around the TRESOR patch to find out how the password that is asked on startup is treated: It is iterated „2000“ times through SHA256, as their paper states.
Well, it cost me many hours to find out the little quirks about that:
- It’s not actually iterated 2000 times, but twice in each loop run, and the loop runs 2000 times, thus 4000 times. And once before that. So actually it’s iterated 4001 times through SHA256.
- There is no way to specify an iteration count to
cryptsetup for standard dm-crypt devices (only for LUKS).
cryptsetup itself modifies its input: If you pass it a keyfile, it is directly used as key without further processing. But if you pass it a password on stdin, it is (once!) passed through a selectable hash algorithm to form the key. But beware: The stdin-processing also takes place if you pass it
--key-file=-, which should read the keyfile from stdin (weird). Workaround: use
As there is no way to specifiy iteration counts (as we would need it), I implemented the iterated hashing myself by first copying parts of the original patch into a standalone C program and after verifying it actually works, hacking together a bash script to do the same thing. While this script takes tens of thousands times longer than the C program (literally! Nearly 20 seconds compared to instant), it doesn’t need compilation and runs on nearly any system with basic tools like
So the bottom line is: If you ever need to mount a TRESOR volume without having a TRESOR-patched kernel at hand, use the following little script instead, either to generate the keyfile you pass to
cryptsetup or to directly call it: