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

[ethbr1]

> "pull pin to destroy"

Insert old joke about folks rigging a packet of thermite with an igniter over their hard drive.

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

[veeti]

Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.

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

[solenoid0937]

It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation

[dlcarrier]

Just a PIN? For most people that's a 4-digit number, which has a worst-case scenario of 10,000 attempts and a median of only a few hundred. Why not use a full 8-digit password?

[GordonS]

If you're really serious, you use a strong password, not a PIN.

[xnickb]

If you are at all serious about security you don't consider Windows.

Depending on how serious you are you also don't consider MacOS.

And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model

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

[bri3d]

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

First off: I agree with your thesis, BitLocker with PIN is Just Fine, equivalent in all practical senses to most disk encryption strategies, and an enterprise standard.

I post this to reinforce what you're saying, because there are a ton of weird theories about how this works that make people think it's weaker than it is.

BitLocker with PIN works like this:

* BitLocker seals an encrypted key IK into the TPM using a policy on the TPM which requires the SHA-256 of the PIN to be sent to the TPM to unlock the record (and has anti-hammering at the TPM level).

* Encryption using another key called the SK. Once the OS acquires the e(IK) from the TPM, it needs to derive SK to decrypt the IK. The SK is generated by applying a salt and 0x100000 rounds SHA256 to the PIN.

* The IK can then decrypt the VMK, which can decrypt the FVEK which is the actual data encryption key used on the on-disk data.

Fully offline (no TPM access) decryption is hopeless; the IK is random and not attached to the PIN at all.

Fully online decryption relies on TPM anti-hammering; if you can manage to hammer the TPM and find a PIN where h(PIN) matches, you can then use the PIN to generate both h(PIN) (unseal TPM) and reverse e(IK).

Partially offline decryption (imagining TPM content is somehow dumped, for example by bus sniff while a user uses their PIN) relies on bruteforcing the key for e(IK), which is possible but difficult (IMO Microsoft should ratchet this up or use a more expensive algorithm than SHA-256 in order to deal with modern hardware capabilities, but they have issues like FIPS to deal with that make new algorithm selection difficult).

[LtWorf]

https://www.techspot.com/news/112410-security-researcher-mic...

[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

[snailmailman]

Assuming this is what you are referring to, it was resolved within a few days. The incident being resolved just didn't make headlines. https://sourceforge.net/p/veracrypt/discussion/general/threa...

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

[Terr_]

> if you're using a local account

Unfortunately Microsoft keeps working to destroy that option and force consumers to make a remote account. [0][1] Their consistent moves towards wanting to co-own my computer were one of the many last-straws that made me migrate everything to Linux this year.

> Local-only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE). While these mechanisms were often used to bypass Microsoft account setup, they also inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use. Users will need to complete OOBE with internet and a Microsoft account, to ensure device is setup correctly.

[0] https://blogs.windows.com/windows-insider/2025/10/06/announc...

[1] https://www.windowslatest.com/2025/10/07/microsoft-confirms-...

[gruez]

Not to mention that unless the bitlocker activation flow changed recently, it specifically asks you how to store your backup keys, with a choice given been local options (eg. usb drive, printing it off, etc.) and saving it to your microsoft account.

[LtWorf]

Like it's easy to create local accounts on windows 11… the default are microsoft accounts and microsoft having access to your key.

Also this: https://www.techspot.com/news/112410-security-researcher-mic...

[Groxx]

Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?

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

[dijit]

if by "great" you really mean "fine".

It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform.

Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.

[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