[flagged]
AI reply, triggered my spidey senses
Yup look at the rest of their comments
Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
201–210 of 247 posts
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#202Earlier quoted context omitted.
> If you use your key every day you tend not to forget it. hoping users don’t forget their password is a very weak policy. specifically, the policy and admin points you brought up above, how does veracrypt solve them?
You don't have remote back ups enabled?
veracrypt does not include a remote backup system
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#203Earlier quoted context omitted.
You’re being downvoted because you’re taking a narrow edge case and saying it invalidates all usage. Disk encryption is not “technically useless” when it works for 99.999+% of the people using it who aren’t targeted by professional attackers. Most people expect it to protect them against an unskilled thief or when they resell the device, and it works for that. People in those high risk categories already need more th…
Yes I understand all that. I don't have secure boot, so I'm not protected against the evil-maid attack either. I know that too. It's why I used the word "technically", by which I meant "in the absolute". What word do you propose instead? Encryption that can be worked around by anyone with skills and commonly available equipment is technically useless. It offers some protection (the thief will probably reboot or unplu…
I would talk about threat models. There’s a bunch of detail to cover but the short of it is “you’re protected when you resell the device or replace a drive” or “you’re safe from a laptop thief in a coffeeshop but not the Mossad”. How you get there is the step in the conversation after you decide which of those concerns you.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#204But if you do this, don't you have to enter two passwords each time you wake? One for LUKS, one for the system login?
The other big problem is that all your processes continue running, but your disk is unmounted. I can't imagine how you'd avoid everything crashing horribly.
I mean, I can imagine an implementation where the system pauses all processes related to the user session _except_ the screenlocker, and have a custom screen-locker which can supply the credentials to luks…
But that the screen locker is a desktop application, so the compositor itself needs to stay alive too, but then compositor might try to talk to other applications, and those are frozen. So wouldn't it consider them crashed and disconnect them? Now your compositor needs to understand that the system is in a "disk unmounted and processes frozen" state too.
Not even sure how you'd deal with logs from its stdout, since the file descriptor to the log files is invalidated too.
If anyone is actually using such a setup, I have so many questions. I know that theoretically all this is feasible, but all the existing components don't seem to be ready for just unmounting the encrypted disk at runtime like that.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#205LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#206Earlier quoted context omitted.
Exactly. Cryptsetup wouldn't know about the extra copy of the volume key in kernel memory. Which is why, dramatically, it appeared secure ("surely I wouldn't be asked to resupply the passphrase if the volume key is still in memory, right?").
You need to get quite specific on actual attacks to call this insecure to be clear. Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.
I mean, isn't the threat model here that the attacker has stolen your device? That is about the only thing full disk encryption is good for.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#207LUKS still keeps unencrypted header on the harddrive; real men use plain dm-crypt instead! Plausible deniability compatible.
Ah yes, it is very plausible you just keep a partition of hundreds of gb of perfectly random data for no reason at all.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#208While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested. I still find this impressive, and it is nice that we…
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#209I don't see any other way? When you sleep (suspend to RAM), everything is stored in RAM and is encrypted but the master key is present in kernel memory (if I recall correctly). However, if you hibernate (suspend to disk) the entire contents of RAM (including the master key) is written/encrypted to disk and the RAM is cleared. When you wake the machine up you have to re-enter the passphrase to decrypt the master key t…
Yes, if you simply suspend your laptop on most stock Linux distributions, then everything including the master key is still kept in memory. But Debian pioneered the (optional) cryptsetup-suspend addon. This issues a luksSuspend command which is supposed to wipe the key from memory, and on resume asks you to resupply your passphrase. Up to kernel 6.8, this worked as described; starting with kernel 6.9, it silently did…
The luks feature is not Debian specific
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#210To me the bigger problem is that the linux kernel does not seem to have a thorough test suite. Such things should be easily testable and verifiable. Apparently since 2024 nobody had that; humans are only so good for some tasks. Automatism should be done programmatically by machines serving humans. Edit: Wait, so this was a debian patch? Now, this does not nullify my prior statements, but they should have said so clea…
No, it is indeed a kernel bug in the code path responsible for luksOpen.
Debian (and the distributions which ported cryptsetup-suspend) relied on cryptsetup luksSuspend doing its thing correctly, and cryptsetup luksSuspend relied on cryptsetup luksOpen doing its thing correctly, and cryptsetup luksOpen relied on the thread keyring being purged from memory on process exit, which is promised in the tread-keyring(7) manpage.