That's right. This is a sequel. But unlike most it should be part of the good ones.

As readers of my previous article on encryption might know, I take my privacy at heart - even though it gets increasingly hard in this digital era.

But let's not lose focus here. I share the interest in encryption with a few friends of mine, Teran being one of them. He hinted at a design flaw that affects a lot of mainstream encryption schemes - Microsoft's BitLocker, Apple's FileVault, but also open source solutions like dm-crypt or TrueCrypt.

All those implementations seem to store encryption keys and passwords in RAM - but in an unencrypted manner. Due to the nature of RAM, its contents don't get erased immediately after a system shutdown. The suspend and hibernation states, obviously, suffer from similar vulnerabilities.

In my previous post concerning disk encryption, I explained how to use LUKS, which relies on dm-crypt, and the framework Arch Linux provides to automate mounting of LUKS-managed partitions during the boot process. Since I am a bit of a security freak, I decided to move to loop-AES, which supports key scrubbing.

The big drawback to using loop-AES is the lack of support by LUKS and thus (for Arch users) by the encryption hook. This means the mounting procedure cannot be automated; at least, not to my knowledge. I performed some tests and was unable to get the loop-AES prompt to accept any input other than stdin, just like e.g. ssh-agent. If anyone thinks I'm wrong, let me know how this can be done, but I think developers choose not to implement it because it can be a security risk. Having your password/passphrase reside in a plain text file on your hard drive is as bad as having them in RAM; worse, even.

Another inconvenience to loop-AES is that, unlike LUKS-supported encryption schemes, it is not supported by the mainstream kernel. This means that installation is less straightforward - invasive, even: the loop-AES project contains a re-implementation of the loopback device and will completely replace the kernel's code for it. Other than that you need to patch util-linux-ng (which provides mount and other utilities) to work with the new loopback code. Arch's util-linux-ng already has the project's patch applied.

There are two ways to go about the kernel side implementation. You can compile the module against your existing kernel, which requires you to rebuild the module at every kernel upgrade. This method is will not work if you have the loopback code compiled in statically.
The second option is using the author-provided patch (contained in the source tarball) to patch the kernel source and build your own kernel. I prefer the latter, it makes for a cleaner build in my opinion, and it minimises your maintenance efforts - that is, if you build your kernel yourself.

However, the author-provided kernel patch needs some work. You still need to to remove the loopback code manually before applying the patch to the kernel source. The patch itself will completely re-implement the loopback device and add some extra stuff, like the key scrubbing I am interested in. You can then tick the options in the kernel configuration menu.

I do not quite understand why the developer asks you to remove the loop.c and loop.h files manually from the source tree while a patch could do that as well. I have followed his procedure and rediffed the trees to build a patch that takes care of the whole procedure. Patches have been created against 2.6.26, 2.6.27 and 2.6.28. This is only out of laziness - there is no difference in code whatsoever between the patch the author provides and mine.

Have fun with them :-).