Live data from Hacker News

Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

mathstodon.xyz

31–40 of 247 posts

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#32

Earlier quoted context omitted.

Oh, which one is it? (You don't mean BitLocker, right?)

It absolutely is and they have most the enterprise market.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request.

https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#33

Earlier quoted context omitted.

I wonder if you think other OSes are any different? TempleOS is the only thing that comes to mind that doesn't fit your description and it's not practically useful. Any sufficiently large codebase is a mix of ideas and concepts implemented by different people with different priorities over a large timespan and if you can fit the entire thing in your head it's not very interesting or complex.

The *BSDs, Mac, and Windows all keep critical code in the same tree as the OS. Something like disk encryption would be immediately visible. So you don't have this mess of 80 different distros with 60 different versions of systemd, 20 that don't use it, a million kernel versions and it's all thrown together in a Costco-sized trash bag and we call the output "Linux".

In my experience any software system (not just operating system) after crossing a certain limit on complexity and age looks exactly as hodgepodge of code pieces thrown together, sometimes from different sources even if developed by one org. All major OSs have long crossed those limits, I believe.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#34

Earlier quoted context omitted.

Oh, which one is it? (You don't mean BitLocker, right?)

It absolutely is and they have most the enterprise market.

Okay, yes, sure. It definitely is the most-used encryption software for Windows.

But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others:

38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#35
post #32

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

Does that mean it's not the de facto standard on Windows?

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#36
post #32

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

for enterprises, where this doesn't really matter, bitlocker is great.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#37

[flagged]

I wonder if you think other OSes are any different? TempleOS is the only thing that comes to mind that doesn't fit your description and it's not practically useful. Any sufficiently large codebase is a mix of ideas and concepts implemented by different people with different priorities over a large timespan and if you can fit the entire thing in your head it's not very interesting or complex.

Qubes OS, the Linux distribution aspiring to offer a reasonably secure operating system, pioneering a "every app runs in a virtual machine" approach in the Linux laptop/desktop space, tracks this at the following issue:

https://github.com/QubesOS/qubes-issues/issues/2890

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#38
post #32

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#39

I 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…

So you would still be asked for a passphrase, even though it's already available?

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#40
post #30

> Except that, for more than two years, the encryption key remained resident in memory across suspend, leaving it there for the taking by anyone who seized the still-powered laptop. I don't get it. Obviously, the laptop is locked when it resumes, how is that key "for the taking by anyone"? I'm not saying it is impossible to read out RAM from a locked laptop, but surely not by "anyone".

Anyone with physical access. I think it is understandable from the phrase.

There is a common misconception about how lock-screens in general work - they usually just prevents using the current hardware and software as it is to access the current OS. But the disk encryption is the main thing that prevents modification and other kind of access to actual data. And if the disk encryption key is lying in the memory, then effectively, the disk encryption is bypassed if someone can access the machine physically and assuming that there are no sufficient tampering protections in place for that machine.

Post reply on HN