Hacker News

Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists.

Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend.

Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.

Only the current stable (13/trixie); bookworm shipped with 6.1 as the main kernel (with 6.12 available in backports).

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

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.

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?

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

The luks feature is not Debian specific

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)

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

Correct.

The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend?

edit: I see now that the prompt was being given and the keys still resided in memory.

And assuming the crypto algorithm has no fundamental flaws, it's applied correctly, and the software implementation has no bugs.

All of which are things people have on occasion believed to be true and found out later they were wrong about.

Agreed. It's also very low effort and as such I'm ok with the redundancy.

I agree re Rust vs C - this is not (only) a language issue. What would (roughly) the invariant be here?

In another thread comment below i argue that maybe the system (OS) itself is so complex that it lacks clear contract / the contract evolves too quickly over time (as other parts of the code need to change the given piece of code to extend it to their use case) and that defies clear encoding?

Or we lack easy enough means to describe specs? I tried reading jepsen spec earlier today and despite it being an "integration test" of sorts, it is far from "simple".

Can an entire OS or a system of comparable complexity be decomposed into objects simple enough that their entire intended behavior (with all edge cases) can be explained in a paragraph of human text + half a screen of dense behavioral "spec" - if i do X and do Y, Z should come out / hold _no matter what happens in-between_. Or that's what asserts + fuzzing is effectively supposed to do? Is there a clear distinction between invalid input and failed invariant in typical C code? I guess error code vs seg fault?

This is in effect a state machine, and when you have a type system more complex than C's you can encode state transitions in the type system (either by having state transitions explicitly return a new return type or by using sum types). You still need to architect the system to encode the invariants in types. No language will fix all logic bugs for free. But you can leverage language features to reduce their number.

If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.

I think https://news.ycombinator.com/item?id=48766436 is a practical answer. A marker that can't be forged (without explicitly malicious code being written), which is needed by the "yield to suspend/shutdown" function.

Missing the "wipe key from memory" means you don't have the marker, and trying to continue the suspend/shutdown will fail to compile, because you don't have the marker.

Yes, I agree. I find the addition of the regression test the true long-term fix. The code is just an opaque incantation that may or may not preserve some property we find worth preserving and we have no way of knowing it keeps preserving it over time as other parts of the system change.

The test actually proves it and while it too can change it has more staying power because it's expressed at a higher level of abstraction ("random arcane weird C shit" in the case of code versus "does this property hold" in the case of a regression test).

On the other hand, it is (both halting and spec adherence) are checkable under compute and space constraints though? :) I'd say the biggest hurdle are means to describe the spec in way that is easy enough for a human to produce to make it feasible.

Not a DB person either, but things like TLA+ seem very hard to write even with LLMs. Behavioral tests with an enumerable number of random paths to take (aka model checking - eg jepsen) seem more feasible. Although you can't check internal properties of the system (string `pass` or any of it's copies or parts are not held anywhere in memory at any point between lines A and B) unless we can check that two memory dumps are indistinguishable with different pass strings (assuming we abstracted away storage devices in a test environment).. Also not sure if it's "easy enough" to write such tests either.

Maybe the reason is that OS domain objects / primitives are too complex and not "isolatable" enough / lack a clear contract at all? (Hence multi file refactorings that break invariants.)

Not sure why you're getting downvoted, this is the entire point of open source.

Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where?

Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is now being replaced by another back-door.

Maybe but still a little better than closed source like Windows. Everytime whem someone asked me if I could hack my way into his Windows PC I always told "After all it's Windows, how bad can it be?" Doing that since 25 years still waiting for a Windows machine that doesn't open... On the other hand I failed to open about 50% of Apple Devices I was asked to open and about 10% of Linux machines. (Not because Linux is insecure by itself but because most Linux distros install with insecure defaults and users don't care.)

The whole point of luksSuspend is to not have the encryption keys in memory, as that actually does mean they could be extracted by an attacker who has taken the hardware.

Yup look at the rest of their comments

Interesting idea. On the other hand on the latest SSD with hardware encryption the raw disk speed under Linux can be over 5 GB/s so on my laptop with 64 GB of RAM the full restoration from disk takes like 45 seconds. With LUKS it is like 2 times slower. Which is not a problem at all. So I do not see much value in memory encryption in suspend.

    > where does it get a key to decrypt memory on resume?

Anyone with physical access, significant tools, and experience. The FBI has people who can pull data out of memory after freezing the RAM but the average laptop thief doesn’t so how serious this is depends significantly on your threat model. If you’re not a major criminal, bitcoin whale, or intelligence target this is almost certainly academic.

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

Sorry, I'm probably dense, I still don't get it. You steal a laptop, you open it, the screen is locked with a password/fingerprint whatever. How do you read out the RAM from that laptop?

Do you mean with with current software? How to avoid it in general is straightforward.

If you're the only one with the disk password then the simple answer is make both passwords the same and make the different parts of the system communicate better.

If you want multiple users, give them each a different boot password and encrypt a separate copy of the disk key with each one. That password can be their login password too, or it can encrypt their login.

I have always been thinking LUKS was supposed to be enrolled in TPM, so you should not have to enter this key manually; this is just to prevent someone from unplugging the hard drive and reading on another machine. Of course, this depends on one's threat model.

This is correct, the memory encryption stuff is to prevent side channel attacks, not secure data.

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

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