[bitbasher]

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 to re-load disk contents back to memory.

[IngoBlechschmid]

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 didn't.

[herywort]

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

[IngoBlechschmid]

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

[pedrocr]

It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.

[IngoBlechschmid]

Yes, you are right: LUKS encryption protests your data at rest. An attacker which steals your disk can only gain little, like the information that you have used LUKS (unless you put your LUKS headers elsewhere, separated from the disk) and perhaps disk and disk sector usage statistics.

[Guvante]

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.

[comex]

I don’t know about “almost all”.

If the key has been purged but you can read RAM, then you can do two things:

1. You can extract whatever user data happens to be in RAM.

2. If you can either write RAM or reboot into your own OS, and then return the device to the unsuspecting user who will put in their password, then you can run a fake password dialog and get everything.

1 is bad, since there may be quite a lot of user data in RAM. But it’s not quite as bad as having the disk key, which gives the attacker all the data plus the future ability to decrypt or modify user data given only the physical disk. (Still, a better solution would be encrypting the hibernation image, preventing this attack entirely.)

2 is fully bad, but in many plausible scenarios (e.g. seized device) the attacker cannot just return the device to the user without them knowing something happened. Or even if they can, the method of RAM access may be one where reads are much more practical than writes, such as cold boot attacks involving physically swapping out the RAM.

[XorNot]

The seized device scenario is starting to get very specific though: in the actual cases it's relevant like the Silk Road take down the device was intercepted while open.

It's of some frustration to me that more security devices don't have a "pull pin to destroy" function available in them for this reason if you have any type of threat model where this applies: e.g. when I thought about using a Yubikey to secure remote access, a core problem is you can't quickly wipe a Yubikey in your possession - and while they're fragile in daily use, they're also surprisingly hard to intentionally destroy quickly.

[Guvante]

You need to only have the ability to execute code after the hibernation not before and the machine needs to be permanently unavailable to the user after.

As I said quite rare situations.

If you can read this kind of data you have the ability to run code which means you already owned the entire operating system making capturing the key next entry beyond trivial.

You don't need to spoof anything, we assume here you can read the key from RAM remember.

If you could execute code before hibernation you similarly already had the key.

[bawolff]

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.

[Terr_]

It also prevents the addition of content onto the disk, providing tamper-protection in addition to secrecy.

For example, spyware/remote-control software would open new routes to penetrate your employer's systems, or steal money from your bank account, bypassing other security measures like an additional layer of encryption on your password mode, or 2FA.

Even a relatively unsophisticated foe could connect your hard drive, dump incriminating data on it to frame you, put it back, and then call the authorities with a tip.

[Guvante]

You are generally guarding against the device being shutdown.

Anything assuming the OS is running is already into "well that is easy" territory since if the OS is running those keys are in the same place as this attack leverages.

[Groxx]

I've been wondering why hibernate didn't work with encryption, because this seems like the extremely obvious way to handle it, but I have struggled to find anything about it for years - glad to hear it does exist!

But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.

[reirob]

For me it works and I use it all the time. I hibernate with:

sudo systemctl hibernate -i

And when waking up it requests the LUKS passowrd. Using NixOS, worked since 2019 or so.

[naturalmovement]

FYI: VeraCrypt is not the defacto encryption software for Windows.

[IngoBlechschmid]

Oh, which one is it?

(You don't mean BitLocker, right?)

[naturalmovement]

It absolutely is and they have most the enterprise market.

[IngoBlechschmid]

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

[bri3d]

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed).

BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.

[noinsight]

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

[akimbostrawman]

>But I would never trust it a second, being proprietary and known for issues

While true if you don't trust the proprietary encryption you shouldn't trust the proprietary OS either. I think bitlocker backdoor or bugs should be the least of your concerns when the OS is literally known for covertly exfiltrating data to the cloud.

[naikrovek]

If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you.

Bitlocker + PIN is as secure as anything.

A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

[saidnooneever]

veracrypt lost their drivers license so afaik you should avoid it since it cannot update its drivers any longer. didnt see any news about them reacquiring that license

[nacs]

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...

[Terr_]

Tangentially: Microsoft telemetry collects the serial# of your devices and reports it (with your IP and MS account) back to the mothership, and some printers embed their serial# in printed pages.

So take countermeasures if you print something out criticizing any groups that abuse political or law-enforcement powers.

[andrewpiroli]

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.

[briHass]

Bitlocker can use keys that are local only, but the default for home editions of Windows was to use the online account to back it up.

'Happily' is also a stretch, as they really don't have a choice if served a valid court order.

If you want encryption that is safe from the US government, keys need to be stored in your head. Anything physical is subject to court orders.

[philipallstar]

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

[naturalmovement]

So exactly like FileVault?

[john_strinlai]

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

[dathinab]

makes me wonder if there is potential for a more "main stream"/by default friendly version of this, where the key during suspend is encrypted using the TPM even if the TPM isn't a possible unlock from cold boot (i.e. no TMP encrypted volume key in the LECS headers/meta only temporary in memory during suspend)

or the alternative (for more convenient usage) for single user systems auto login on boot + use disc password for doas/sudo?

[michaelmrose]

The luks feature is not Debian specific

[dist-epoch]

Both Intel/AMD CPUs produced in the last 5 years or so support full transparent (to the OS) memory encryption. So cold boot attacks are a thing of the past if you enable this feature (it's typically disabled because it reduces RAM speed by about 0.5%).

[tredre3]

The impact on performance is more along the lines of 1-2% on AMD (though it likely varies by generation (I did extensive benchmarking on Renoir wrt throughput/latency/gpu). But yes small enough to be insignificant unless you run LLMs or game on the iGPU. I imagine that it also uses marginally more power.

AMD also has a second encryption mode where the OS decides what gets transparently encrypted, it doesn't have to be everything. But that mode is poorly documented (or at least the documentation isn't accessible to peasants like me)

[m3047]

Recent news is that this isn't shipping on some consumer-grade CPUs from AMD. There, made it explicit enough there's no room for conversation. Here's the link:

https://arstechnica.com/security/2026/06/users-cry-foul-afte...

[dlcarrier]

AMD backtracked on that strategy: https://www.techpowerup.com/350142/amd-to-restore-tsme-memor...

Future AGESA updates will still include memory encryption for all processor models. It's one of the rare instances of consumer backlash creating a clear and immediate response.