Dear Tim and Jonas

Although the third commentator IS right, all progress has its risks and I have not found anything, anywhere else, that comes near to solving this problem. Furthermore, methinks it short-sighted of those who implemented LUKS disk encryption not to think about this problem. Please carry on with the good work and I, for one, will use it and report back.

Thank you for your effort.

Andrew

This project leaves a lot to be desired. You remove LUKS keys from the RAM, yet everything else still stays in the RAM. Sure, this does protect your LUKS disks. However, if your attack model is someone being able to read data from the RAM, you wouldn't want anything to remain in the RAM. You would want to suspend to disk and power off the laptop, which would lock all LUKS volumes and power off the RAM, leaving the attacker unable to read anything. With laptops using nvme ssd with over 2gb/s read/write speeds for the boot drive, suspending to disk and resuming from it is very fast, and you get the benefit of leaving nothing in the RAM for the attacker to read and having empty RAM for all your argon2i needs when you resume the system.

@Tom: unfortunately, cryptsetup-suspend will not work with sys-v-init without major rework. As explained in the blog post, it depends on systemds cgroup management and utilizes the systemd-suspend.service. See Technical challenges and caveats.

Very interesting project - thanks a lot! Would sysv-init users have to customize the code you provide or can it be expected to work out-of-the-box (excepting its experimental status of course)?

I am using Windows 10 myself. Very happy with it :)

At least use https when downloading packages like that.

Or add it to sources.list and pin it down…

@joeyh: The password prompt is meant to be a security boundary protecting the content of an encrypted block device. Its purpose is not to protect against the spawning of a rescue shell.

If the password prompt is not intended to be a security boundary, it should be removed.