Is LUKS as secure as VeraCrypt on Windows?

8Zephyr · 2024-08-21 22:55:58

Hello everyone! I have a laptop where I need to store important data, so I need to take full disk encryption seriously. If I use LUKS for encryption, will the keys be encrypted in RAM? Is it possible to extract them by dumping the memory? Also, is it feasible to set up a dual-boot system where entering one password grants access to one partition, while entering another password grants access to a different partition, similar to how VeraCrypt works?

If LUKS cannot provide this functionality, what can I do to make it possible?

Last edited by 8Zephyr (2024-08-21 23:02:22)

Awebb · 2024-08-23 07:49:47

I'm sorry if I come across like some sort of huge dick, but are you sure you could use the information provided here effectively? What if one said "yes"? Would that really help?

The thing with the two passwords is called "plausible deniability". You should research "LUKS plausible deniability".

seth · 2024-08-23 08:04:33

Veracrypt ist in the repos.

Not Sure about encrypted master Keys (are you concerned about cold boot attacks?), the approach seems to be to ensure the Container gets closed on shutdowns, but that's Not gonna Help with HW Access.

lrdoftheblings · 2024-09-07 21:24:25

8Zephyr wrote:

If I use LUKS for encryption, will the keys be encrypted in RAM?

The volume key has to be loaded into memory in order to access your data. There's not really a way around this.

8Zephyr wrote:

Is it possible to extract them by dumping the memory?

Yes, if your system is powered on and the container unlocked then an attacker with physical access to your device could extract the keys from memory with the right equipment. If your threat model includes attackers with these kinds of resources then you are asking for help in the wrong place.

8Zephyr wrote:

Also, is it feasible to set up a dual-boot system where entering one password grants access to one partition, while entering another password grants access to a different partition, similar to how VeraCrypt works?

Yes, you can create multiple LUKS containers and they will use different volume keys and you can install OSes on them.

seth · 2024-09-07 22:01:53

The volume key has to be loaded into memory in order to access your data. There's not really a way around this.

The OP is referring to https://veracrypt.eu/en/VeraCrypt%20RAM … ption.html
For everything but cold boot attacks this is security-by-obfuscaturity (VeraCrypt acknowledges that) and I agree that

If your threat model includes attackers with these kinds of resources then you are asking for help in the wrong place.

Since I was posting the last time from my phone, let me add the obligatory https://m.xkcd.com/538/

Strike0 · 2024-09-10 17:47:11

LUKS is a tool for data-at-rest encryption, i.e. when the system/device is turned off. It was never intended for more. A user/process with matching privileges can obtain the master key of an unlocked (not-at-rest) device. An encryption of keys in RAM would qualify as a data-in-use encryption. There were some early academic attempts to add such to the kernel, but it's nothing supported by standard tools and even 'pro' approaches like Intel SGX features have been pwned.

lrdoftheblings wrote:

8Zephyr wrote:
Also, is it feasible to set up a dual-boot system where entering one password grants access to one partition, while entering another password grants access to a different partition, similar to how VeraCrypt works?
Yes, you can create multiple LUKS containers and they will use different volume keys and you can install OSes on them.

Albeit, you cannot automagically address the different LUKS containers depending on which password is entered (this would be a plausible deniability feature), at least with standard tools. In the simplest case you need to create and pick different boot entries for each system to boot. Besides the LUKS headers for each are transparent, so it's not comparable to how veracrypt works.

lrdoftheblings · 2024-09-10 19:40:26

OP never said anything about plausible deniability. It read to me like they want to have work and personal data separate and compartmentalized or something similar.

seth · 2024-09-10 19:45:12

is it feasible to set up a dual-boot system where entering one password grants access to one partition, while entering another password grants access to a different partition, similar to how VeraCrypt works?

If the password alone determines the target container, that typically targets plausible deniability.
You've two volumes, one full of porn, the other one only contains cat videos. Your mom forces you to unlock the container because she what's to know what filth you're keeping there. You're entering the "wrong" password, it works, the volume gets decrypted and hear "Awwww, pussies" instead of "Eeeww, pussies".
It's relevant because of https://m.xkcd.com/538/

johnspack · 2024-09-16 04:11:05

Just a note... Veracrypt allows you to create a hidden volume within a volume, with a different password.

xfluxmaxer...x! · 2024-12-29 02:45:54

I found these answers on the memory encryption glaringly lacking, so I was compelled to create an account to comment on a 4 month old thread.

Most modern consumer devices - laptops, phones, commercial and business desktops - ship with full-memory encryption enabled by default. This includes ARM-based macbooks, all AMD-based laptops and desktops I'm aware of (which granted I'm not omniscient), and all iOS devices and major-brand Android devices.

The exception is consumer-grade Intel CPUs (man they are killing it lately aren't they), some off-brand Chinese Androids. And pretty much anything you build yourself, you should assume you'll need to go into the bios and enable it yourself because it won't be turned on by default.

On AMD it's called "TSME", for Total Secure Memory Encryption, IIRC. On Intel Xeon and most ARM products, it's called TME, for Total Memory Encryption.

It's transparent to the OS and even the CPU - the controller sits between the CPU and RAM.

(BTW you won't read this anywhere in marketing literature or product FAQs, but if you run SEV/TDX on your VM servers, AND TSME/TME, you're doubly-encrypting your VMs in memory. That adds effectively nothing to security, but doubles latency. However the latency on modern hardware is so low, that it's usually - not always - worth it to run both. But SEV/TDX is only available on server-oriented CPUs.)

But all decryption keys and all decrypted data that is kept/cached in RAM, is encrypted in RAM.

It uses the same key storage mechanisms as TPM. And since said modern CPUs have the TPM within the CPU, there's none of this "highly-trained evil maids with a soldering irons and 30 minutes alone with your laptop" fearmongering nonsense to worry about. Also AFAIK it's not affected by the various secure boot debugging key laziness, but I could be wrong.

So in other words, if the Russian Mafia wants the secrets in your RAM, they can't just casually pull the sticks out and plop them in liquid nitrogen. They have to take your whole system in-situ, without losing power to it.

TSME/TME + LUKS/VeraCrypt/or even Bitlocker with your own key, is a very robust start for basic privacy and security, and a necessary baseline to build on for even more paranoia.

Others have mentioned you might want VeraCrypt if you want nested volumes/passwords. I agree, but LUKS can functionally accomplish the same thing, albeit without the plausible deniability of VeraCrypt (which you never mentioned only someone else did).

With LUKS, you can create the underlying full-disk encryption, then a regular filesystem, then a large loopback file within that filesystem - then you rinse/lather/repeat with LUKS and a filesystem within that mounted loopback file. But it's not "plausibly deniable".

VeraCrypt saves you a step with the filesystem, and provides plausible deniability - it's been a long long time since I understood this, but I think it puts the nested container directly within the underlying container, without a filesystem in between. I'm a little fuzzy on the details but I think there's a risk you can accidentally overwrite the nested container with the nested filesystem. I used to understand all that when I used its predecessor TrueCrypt some 20+ years ago, but I don't fully remember the details now.

Hope this helps dispel the rampant disinformation - or really lack of current understanding - around the security of decryption keys in memory.

OP what did you ever wind up doing?

Last edited by xfluxmaxer...x! (2024-12-29 02:51:35)

seth · 2024-12-29 10:02:19

Where in this thread do you see disinformation - it's mostly speculation about the OPs actual perceived threat vector and notably speculations about cold boot attacks are still valid because

as you yourself wrote:

Most modern consumer devices … The exception is consumer-grade Intel CPUs

puts the nested container directly within the underlying container, without a filesystem in between. I'm a little fuzzy on the details but I think there's a risk you can accidentally overwrite the nested container with the nested filesystem.

https://veracrypt.eu/en/Protection%20of … lumes.html
tl;dr this only works by making the outer volume a read-only dummy, becuase if you place anything into unused sectors of a filesystem (so not eg. shorten the FS against the Volume/Partition) and don't tell the (writable) FS to exclude those sectors (which both is easily detectable once the container is decrypted), you can kiss your hidden data bye-bye very quickly.

Also

You wrote:

without the plausible deniability of VeraCrypt (which you never mentioned only someone else did)

Awebb wrote:

The thing with the two passwords is called "plausible deniability". You should research "LUKS plausible deniability".

The OP wrote:

set up a dual-boot system where entering one password grants access to one partition, while entering another password grants access to a different partition, similar to how VeraCrypt works?

While the OP didn't use the specific terminology, Awebb's inference seems a rather reasonable interpretation of the casual description?

And, once again and the russian Mafia in particular still doesn't need any of this.
I'm pretty sure they have the $5 wrench technology (might be misiformation, I've no first hand experience and would prefer it to keep it that way)

Arch Linux

#1 2024-08-21 22:55:58

Is LUKS as secure as VeraCrypt on Windows?

#2 2024-08-23 07:49:47

Re: Is LUKS as secure as VeraCrypt on Windows?

#3 2024-08-23 08:04:33

Re: Is LUKS as secure as VeraCrypt on Windows?

#4 2024-09-07 21:24:25

Re: Is LUKS as secure as VeraCrypt on Windows?

#5 2024-09-07 22:01:53

Re: Is LUKS as secure as VeraCrypt on Windows?

#6 2024-09-10 17:47:11

Re: Is LUKS as secure as VeraCrypt on Windows?

#7 2024-09-10 19:40:26

Re: Is LUKS as secure as VeraCrypt on Windows?

#8 2024-09-10 19:45:12

Re: Is LUKS as secure as VeraCrypt on Windows?

#9 2024-09-16 04:11:05

Re: Is LUKS as secure as VeraCrypt on Windows?

#10 2024-12-29 02:45:54

Re: Is LUKS as secure as VeraCrypt on Windows?

#11 2024-12-29 10:02:19

Re: Is LUKS as secure as VeraCrypt on Windows?

Board footer