Earlier quoted context omitted.
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
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.
Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
191–200 of 247 posts
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#192Earlier quoted context omitted.
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...
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.
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...
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#193Earlier quoted context omitted.
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.
> 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?
You don't have remote back ups enabled?
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#194Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#195Earlier quoted context omitted.
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.
Like set an generic marker struct IsEncrypted where T is yes or now and only allow its state to change when proven and then write the shutdown function to only take the yes variant?
Yes, that would be one way of doing it. You can model off of the Typed Builder pattern:
struct Builder {
a: Option,
b: Option,
}
struct Val {
a: u32,
b: u32,
}
impl Builder {
fn set_a(self, a: u32) -> Builder {
Builder {
a: Some(a),
b: self.b,
}
}
}
impl Builder {
fn set_b(self, b: u32) -> Builder {
Builder {
a: self.a,
b: Some(b),
}
}
}
impl Builder {
fn build(self) -> Val {
Val {
a: self.a.unwrap(),
b: self.b.unwrap(),
}
}
}
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#196Earlier quoted context omitted.
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.
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 use…
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.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#197Earlier quoted context omitted.
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 did…
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…
[dead]
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#198Earlier quoted context omitted.
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)
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.
Our helpdesk deals with 2-300 users per day that logon every single day yet forgot their password.
This type of thinking doesn't work in large enough orgs dealing with end users.
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#199While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested. I still find this impressive, and it is nice that we…
what debian version first shipped 6.9?
Only the current stable (13/trixie); bookworm shipped with 6.1 as the main kernel (with 6.12 available in backports).
Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory
#200[flagged]
AI reply, triggered my spidey senses