11 ms·

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

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.

naturalmovement 3mo ago
FYI: VeraCrypt is not the defacto encryption software for Windows.
- IngoBlechschmid 3mo ago
  Oh, which one is it? (You don't mean BitLocker, right?)
  - naturalmovement 3mo ago
    It absolutely is and they have most the enterprise market.
    - nacs 3mo ago
      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/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/ https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...
      - philipallstar 3mo ago
        Does that mean it's not the de facto standard on Windows?
      - john_strinlai 3mo ago
        for enterprises, where this doesn't really matter, bitlocker is great.
        dijit 3mo ago
        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.
        john_strinlai 3mo ago
        >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
        akerl_ 3mo ago
        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.
        dijit 3mo ago
        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".
      - andrewpiroli 3mo ago
        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 3mo ago
        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.
        nagaiaida 3mo ago
        dell opts you in without telling you. one day you'll just reboot to an unexpected bitlocker screen and have to figure out whether you're getting ransomwared before eventually digging a key out of your microsoft account you weren't aware was there.
        Groxx 3mo ago
        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?
        qlte 3mo ago
        > are local accounts even a thing any more? Yes, most certainly. You can easily convert to a local account in Settings, and there is still a workaround to avoid using a Microsoft account during install. Or the far more stable and reliable method of using Rufus to create the installer ISO which has an option to use a local account without the hassle. Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired). I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.
      - naturalmovement 3mo ago
        So exactly like FileVault?
      - briHass 3mo ago
        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.
      - Terr_ 3mo ago
        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.
    - IngoBlechschmid 3mo ago
      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-without-a-screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM https://www.youtube.com/watch?v=5eNtT2p12cM
      - saidnooneever 3mo ago
        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 3mo ago
        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/thread/9620d7a4b3/?page=1#43c0 https://sourceforge.net/p/veracrypt/discussion/general/threa...
        saidnooneever 3mo ago
        aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.
      - bri3d 3mo ago
        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.
    - nullsanity 3mo ago
      [dead]
herywort 3mo ago
So you would still be asked for a passphrase, even though it's already available?
- IngoBlechschmid 3mo ago
  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 3mo ago
    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 3mo ago
      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 3mo ago
    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 3mo ago
Groxx 3mo ago
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 3mo ago
  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.
dathinab 3mo ago
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?
- SchemaLoad 3mo ago
  [dead]
michaelmrose 3mo ago
The luks feature is not Debian specific

naturalmovement 3mo ago

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

IngoBlechschmid 3mo ago
Oh, which one is it? (You don't mean BitLocker, right?)
- naturalmovement 3mo ago
  It absolutely is and they have most the enterprise market.
  - nacs 3mo ago
    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/microsoft-gave-fbi-keys-to-unlock-bitlocker-encrypted-data/ https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...
    - philipallstar 3mo ago
      Does that mean it's not the de facto standard on Windows?
    - john_strinlai 3mo ago
      for enterprises, where this doesn't really matter, bitlocker is great.
      - dijit 3mo ago
        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.
        john_strinlai 3mo ago
        >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
        akerl_ 3mo ago
        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.
        dijit 3mo ago
        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".
    - andrewpiroli 3mo ago
      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 3mo ago
        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.
        nagaiaida 3mo ago
        dell opts you in without telling you. one day you'll just reboot to an unexpected bitlocker screen and have to figure out whether you're getting ransomwared before eventually digging a key out of your microsoft account you weren't aware was there.
      - Groxx 3mo ago
        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?
        qlte 3mo ago
        > are local accounts even a thing any more? Yes, most certainly. You can easily convert to a local account in Settings, and there is still a workaround to avoid using a Microsoft account during install. Or the far more stable and reliable method of using Rufus to create the installer ISO which has an option to use a local account without the hassle. Rufus for install + Win11Debloat post-install is a nearly effortless way to get an ad-free, local only Win 11 install that persists through updates which removes pretty much all notorious Win 11 pain points (plus additional customization if desired). I've been doing it for years and so reading Windows 11 complaints on HN always feels like they're coming from a strange parallel universe since I never have to deal with any of it.
    - naturalmovement 3mo ago
      So exactly like FileVault?
    - briHass 3mo ago
      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.
    - Terr_ 3mo ago
      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.
  - IngoBlechschmid 3mo ago
    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-without-a-screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM https://www.youtube.com/watch?v=5eNtT2p12cM
    - saidnooneever 3mo ago
      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 3mo ago
        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/thread/9620d7a4b3/?page=1#43c0 https://sourceforge.net/p/veracrypt/discussion/general/threa...
        saidnooneever 3mo ago
        aah cool, thank you..100% missed the update :). thanks! thats good to read honestly lol. not that i use windows much but i felt it was MS trying to undermine it. happy it got restored and there remains an alternative to butlocker.
    - bri3d 3mo ago
      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.
  - nullsanity 3mo ago
    [dead]

herywort 3mo ago

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

IngoBlechschmid 3mo ago
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 3mo ago
  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 3mo ago
    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 3mo ago
  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 3mo ago

Groxx 3mo ago

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 3mo ago
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.

dathinab 3mo ago

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?

SchemaLoad 3mo ago
[dead]

michaelmrose 3mo ago

The luks feature is not Debian specific