Investigating how to change LUKS (possible past LUKS weakness)

There is informed speculation that argon2i is no longer a secure (or at least ideal) KDF:

https://mjg59.dreamwidth.org/66429.html

I don’t know if it’s possible to change LUKS settings in Qubes. The above link has a nice HOWTO but I’m not sure how it would translate to Qubes - am guessing I could try the suggested changes in dom0.

Searching prior posts, I found a response indicating that Qubes team feels “Customizing the LUKS options is not necessary, since LUKS already ships with secure defaults” which I’m not sure is strictly correct; if my initial install had a weaker KDF is Qubes somehow auto updating my encrypted disk to the new defaults (apparently it is now argon2id) when the defaults change? Seems unlikely but I’d love to be wrong.

The above thread also seems to indicate (?) that updating to argon2id might be incompatible with grub and leave a machine in an unbootable state but not clear to me.

Would be good if users can have some guidance on improving LUKS settings. So maybe some of us users can write that.

Has anyone successfully migrated to argon2id? Any clues as to where to start investigating?

2 Likes

Clemens Fruhwirth, inventor of LUKS, answered on the /r/linux subreddit about this subject.
It’s interesting to read, as well as the comments that follow:

https://www.reddit.com/r/linux/comments/12q51ce/comment/jgpvsqc/?context=3

1 Like

Yes and there is a whole thread on Hacker News debating the particulars but it’s clear that argon2id is highly desirable in certain circumstances such as not having a completely random passphrase (probably most are not fully random, especially as they get longer). Reasonable people can disagree on how the French anarchist’s password may have been cracked but seems highly plausible — reasonable users may believe — than it’s an important protective step for someone at risk to use the best KDF available, particularly when Matthew Garrett recommends doing so.

The best argument for upgrading KDF is that the luks2 default seems to have changed numerous times in a relatively short period of time. I’d certainly rather be using the new default than the old (or N generations old) one.

To be sure this problem goes beyond Qubes — Garret’s post talks about how most distros do not enable changing LUKS KDF in a user friendly way — but Qubes users are probably more interested than most in solving it.

2 Likes

There isn’t much to solve here.
It’s straightforward to move on from argon2i - I made the change some
time back with no consequences, and there’s plenty of help online.
I haven’t checked that article you reference but it’s a simple one liner
in dom0 - cryptsetup luksConvertKey /dev/XXX --pbkdf argon2id should
do it.

As to grub, this is a non issue.
Qubes doesn’t use FDE - by default it uses an unencrypted /boot.
It is possible to have FDE, and to do the decryption in grub - that’s
where the issues arise. Since Qubes doesn’t use this approach there’s no
problem.

That said, making any change to your LUKS settings carries some risk,
and I would recommend that any one doing so makes sure that their
backups are up to date.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes

It was correct at the time to the best of my knowledge, but since things change over time, it may or may not be correct now. Either way, it is the LUKS project’s responsibility to ship secure defaults for their own software (which I wholeheartedly hope they do) and distro projects’ responsibility to ship with their own secure defaults for their own distros (which, again, I wholeheartedly hope they do). This includes the way they integrate security software like LUKS into their distros, and this includes the Fedora distro we use in dom0. Of course, the Qubes OS Project will do what it has to in order to protect its users, but it really wouldn’t make sense for the comparatively tiny Qubes OS Project to try to compensate for the shortcomings (if any actually exist) of comparatively huge upstream projects like LUKS and Fedora, which I’m pretty sure have orders of magnitude more users than Qubes. That would be looking at the open-source model completely backwards, IMHO.

No, but that’s not what it means to “ship with secure defaults.” That would be in the realm of a security update of some sort, not the settings a piece of security software has by default when it’s first installed. However, Qubes does inherit the newer defaults for new Qubes OS releases (e.g., in virtue of using newer Fedora releases than before), so it actually is true, in that sense, that Qubes changes when the upstream defaults change, but that obviously only helps with new installations. (This is why new Qubes installations don’t still use PBKDF2 in LUKS, for example.)

More importantly, though, I wouldn’t expect low-level software, in general, to automatically change existing settings when a new default setting is chosen, as this is a good way to mess up people’s systems. Example from the article:

Also, if you’re using an encrypted /boot, stop now - very recent versions of grub2 support LUKS2, but they don’t support argon2id, and this will render your system unbootable.

Many users on this forum have discussed encrypting /boot, and many of them are probably actually doing it, so you can see why we couldn’t just push an update that makes all of their systems unbootable, even if we thought the change were a good idea otherwise.


To be fair, the term “full-disk encryption” (FDE) usually refers to encrypting everything on the disk except for the boot area. For example, even the Wikipedia article on disk encryption states:

The expression full disk encryption (FDE) (or whole disk encryption) signifies that everything on the disk is encrypted, but the master boot record (MBR), or similar area of a bootable disk, with code that starts the operating system loading sequence, is not encrypted. Some hardware-based full disk encryption systems can truly encrypt an entire boot disk, including the MBR.

The MBR is a boot sector on the disk, which contains a boot loader -
it is not /boot.
I accept the common use of FDE for a disk with encrypted partition(s)
which contain /boot, and a clear MBR.
Qubes doesn’t have that - it has an unencrypted MBR and an unencrypted
/boot. You can transition to an encrypted /boot , as you say, which is
an improvement imo.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes

I thought that was covered by the “or similar area of a bootable disk, with code that starts the operating system loading sequence” portion.

Wait, are saying that most Linux distros that claim to use FDE also encrypt /boot and that Qubes is an outlier in this regard? I thought we were using both LUKS and the term “FDE” the way most distros do.

I understood it in the same way that area of a bootable disk is /boot, because the reference to boot disk says it is GRUB or SYSLINUX with kernel and initrd.

But unman’s definitions makes more sense, and it’s inline with what the article calls true FDE.

Some hardware-based full disk encryption systems can truly encrypt an entire boot disk, including the MBR.

1 Like

No - these are very different things.

I don’t know what most Linux distros say. I suspect they tend not to
claim to use “FDE”.
In Debian, there is an explicit contrast between “encrypting the whole
system” and excluding /boot - the debian-installer doesn’t support
encrypted /boot but there is a separate guide on the subject, which
begins:

So called "full disk encryption" is often a misnomer, because there is typically a separate plaintext partition holding /boot
```

In Arch, the documentation covers encryption of /boot as part of
"encrypting a whole system", and details the plus and negative aspects.
Fedora has "encrypt my data" as an option, but doesn't refer to FDE,
afaik.

There are numerous guides to installing systems with encrypted /boot ,
or converting a stock install to FDE. I could provide one for Qubes if
one was wanted, **but** as in this thread, there's a trade off with
available GRUB/LUKS options. Currently I wouldn't recommend.

<small>
I never presume to speak for the Qubes team.  
When I comment in the Forum or in the mailing lists I speak for myself.
</small>
1 Like

If I have an issue here it’s just with saying something you don’t own is secure - I don’t think that’s usually a wise thing to say to someone, IMO. But c’est la vie.

I appreciate the facts and help in your post. Try to remember, something might be an issue for someone not as smart as you, and telling them it’s not an issue might make them feel kinda dumb :slight_smile: When I say it’s a problem to solve, I mean, for me, and if I don’t know, probably other users don’t either. I’m not trying to make a federal case out of it, just looking for help.

1 Like

Okay, thank you for the correction.

I see. Thank you for the clarification. I’ll update our documentation to better reflect the nuance here.

1 Like

The last time you told this lie, (then about the Forum generally, rather
than me), I sent a long(ish) reply, which read in part:

Notice that this was use of RTFM by anyone - I don’t think I have
ever used RTFM to a user.
Since then there has been some use of RTFM, mainly from a user who is
now banned.
It’s true that I often direct users to the docs, but I almost always
also provide the answer.

I don’t know why @gust feels it necessary to lie about the forum and
other users - Last time he was accusing @adw of “hostility and
swearing”.

Unfortunately the Forum is a public space aimed at Qubes issues, and
doesn’t work like that.
You don’t get to pick and choose who replies or comments on your posts.
You do have a right not to read posts from certain users or not to
comment on them. This is very easy for those of us who interact via email,
and I believe it’s also easy for those who use the web interface.

If you think that posts are moving off topic you can ask the mods to
split or create a new thread.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes

Yes, the forum has both “ignore” and “mute” functionality, which can be found under Preferences > Notifications > Users. The description for the “Ignored” list states: “Suppress all posts, messages, notifications, personal messages, and chat direct messages from these users.” The description for the “Muted” list states: “Suppress all notifications, personal messages, and chat direct messages from these users.” I encourage everyone on the forum who needs these features to use them, even if it’s against me! :slight_smile:

edited

edited

(hopefully) constructive advice

Complaining about other user’s styles / comments has become a sport in this forum. I fail to see how that helps anybody or makes anything better. Yes, I’ve done it too occasionally. If one doesn’t like a post I see three productive options:

  • ignore the post
  • compose an answer pointing out the flaws in a friendly and constructive manner (if it’s on-topic)
  • flag the post for being off-topic, outside the CoC or spam and let the mods deal with it (realizing they don’t sit 24/7 on their computers, won’t spring into action the moment one wishes they would and sometimes might not agree)

On a side note, argon2i/d et al have high memory requirements by default (max. 1 GB per cryptsetup open operation).

So one would probably like to use --pbkdf-memory, if one expects to be able open multiple such containers at the same time or on some low memory devices (e.g. Raspberry Pi or a Qube).

Or stick with pbkdf2… ^^

1 Like

Isn’t the memory used by the KDF released when the key is obtained?

In terms of unlocking Qubes OS, would this not only become an issue if you have a very large number of drives in your storage pool?

1 Like

Of course it’s released afterwards, yes.

And yes, for default Qubes OS disk encryption (2 luks drives IIRC) using 2 GB of memory during boot shouldn’t be too much of an issue. It may be unexpected for those attempting to lower dom0 memory to less than that to have more for VMs.

The cryptsetup maintainers have some safeguard checking for memory during the container creation and using whatever is available and at most 1 GB IIRC. This works not so great if you create a container on a high memory device (e.g. during installation of Qubes OS) and later attempt to open it on a low memory device (e.g. Qubes OS dom0) imho.

For those with uncommon setups and for cryptsetup users inside VMs it may be relevant.

3 Likes