Recent comments on posts in the blog:

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.
Comment by yes Sun 30 Aug 2020 04:45:25 PM UTC
@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.
Comment by mejo Thu 27 Aug 2020 11:33:50 PM UTC

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)?

Comment by Tom Wed 26 Aug 2020 08:34:24 AM UTC
I am using Windows 10 myself. Very happy with it :)
Comment by Angie Wed 05 Feb 2020 09:12:59 AM UTC

At least use https when downloading packages like that.

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

Comment by mirabilos Tue 04 Feb 2020 04:23:30 PM UTC
@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.
Comment by mejo Thu 08 Dec 2016 11:23:20 AM UTC
If the password prompt is not intended to be a security boundary, it should be removed.
Comment by joeyh Wed 07 Dec 2016 03:50:29 PM UTC