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 2 hours ago | parent | next [-]

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

▲

IngoBlechschmid 2 hours ago | parent [-]

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 an hour ago | parent [-]

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 an hour ago \| parent [-]
		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.

▲

naturalmovement 2 hours ago | parent | prev [-]

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

▲

IngoBlechschmid 2 hours ago | parent [-]

Oh, which one is it?

(You don't mean BitLocker, right?)

▲

naturalmovement 2 hours ago | parent [-]

It absolutely is and they have most the enterprise market.

▲

IngoBlechschmid 2 hours ago | parent | next [-]

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

▲

noinsight an hour ago | parent | next [-]

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 8 minutes ago \| parent [-]
		It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation

▲

bri3d an hour ago | parent | prev | next [-]

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 21 minutes ago \| parent [-]
		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.

▲

saidnooneever an hour ago | parent | prev [-]

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 an hour ago \| parent [-]
		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 2 hours ago | parent | prev [-]

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

▲

andrewpiroli 2 hours ago | parent | next [-]

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.

	▲	gruez an hour ago \| parent [-]
		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.

▲

briHass 2 hours ago | parent | prev | next [-]

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.

▲

john_strinlai 2 hours ago | parent | prev | next [-]

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

▲

dijit 2 hours ago | parent [-]

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.

▲

IrishTechie 10 minutes ago | parent | next [-]

We have more issues with FileVault than we do with BitLocker, the latter being a fleet 5 times larger than the former. I find both “fine” for enterprise.

▲

john_strinlai 2 hours ago | parent | prev | next [-]

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

no, i mean great.

managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all).

on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it.

for personal use, i do not recommend bitlocker (or windows, really), but for already-windows enterprises? absolutely

▲

dijit an hour ago | parent | next [-]

Flicking a button to turn something on is not what I'm talking about, that's normally the easy part of any setup, and I judge people harshly who only take that aspect of something into consideration when discussing systems.

Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.

Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.

That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.

If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".

▲

bri3d an hour ago | parent | next [-]

Having dealt with FileVault in this context, it's also frustrating; it's really common to have it fail to follow the logged-in user's credentials, and if you use any kind of federated login, you will frequently get users with FileVault passwords that are either ahead of or behind their system login password.

I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.

▲

john_strinlai an hour ago | parent | prev [-]

maybe i am missing something, but how did veracrypt solve all of the admin and policy issues you’re bringing up? (specifically for large enterprise fleets)

▲

dijit an hour ago | parent [-]

If you use your key every day you tend not to forget it.

If I as an admin give you your key: it is “leaked” effectively.

	▲	john_strinlai an hour ago \| parent \| next [-]
		>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?
	▲	dcrazy an hour ago \| parent \| prev [-]
		Have you never gone on vacation and forgotten your daily-use password upon return?

▲

akerl_ 2 hours ago | parent | prev [-]

Managing an Apple fleet is similarly fine, and that includes using any of the MDM tooling that also does key escrow on enterprise Filevault devices.

▲

dcrazy an hour ago | parent | prev | next [-]

FileVault absolutely has an optional iCloud Keychain escrow. That’s how the “unlock with Apple Account” feature works. Apple doesn’t have the keys for iCloud Keychain, but it is still stored in iCloud.

▲

Arainach an hour ago | parent | prev | next [-]

Veracrypt is more difficult to set up - whether on one machine or a fleet. Bitlocker is a few buttons in the UI, configurable via Group Policy, and so much more.

What is brittle or awkward?

	▲	dijit an hour ago \| parent [-]
		"PLEASE ENTER YOUR BITLOCKER RECOVERY KEY" Where is it? A) Uploaded to microsoft B) Somewhere in EntraID? C) Somewhere in our onprem AD? D) Written down on a scrap of paper when I set up the laptop the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path. It's also like 64 characters alphanumeric with no capability to copy/paste. Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.

▲

j16sdiz an hour ago | parent | prev [-]

> Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else)

Did you read the documentation?

https://support.apple.com/guide/mac-help/protect-data-on-you...

"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."

https://developer.apple.com/documentation/devicemanagement/f...

"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."

▲

dijit an hour ago | parent [-]

Can.

If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account.

If you don't select that option it never does.

I should have said "without your explicit permission", but I assumed we were all adults and understood that.

The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.

	▲	dcrazy an hour ago \| parent [-]
		No, you were just plain wrong. You said “never”, when in reality BitLocker and FileVault both have optional escrow.

▲

philipallstar 2 hours ago | parent | prev | next [-]

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

▲

naturalmovement 2 hours ago | parent | prev [-]

So exactly like FileVault?