Thanks for your efforts in this project. I hope you can help with the following

While I do see the Sleeping..., Resuming... messages on TTY8 and the machine is sleeping/waking correctly, I am not prompted for a passphrase. Might this have something to do that I have both a keyfile AND a passphrase configured for each LUKS device (so 2 LUKS key slots, per LUKS device are in use), and the wrapper is not closing the devices? Or maybe it is closing the devices, but the reference to the keyfile is still present in regular RAM or in your chroot portion of RAM and so it is automatically used by the system on resume?

/etc/crypttab has the keyfile specified, but it is inside the 'would be locked' device...

So the question is probably how to remove the keyfile from memory, close the device and prompt for password on resume.

Thanks for your help with this issue.

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.