Bug 1213345

Summary:	Default LUKS1 encryption should be upgraded to LUKS2 for argon2id KDF
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	JuPing Chan <email>
Component:	Security	Assignee:	E-mail List <yast2-maintainers>
Status:	RESOLVED WORKSFORME	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	ancor, aschnell, security-team
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description JuPing Chan 2023-07-14 13:47:33 UTC

I installed openSUSE Tumbleweed on a new home server this week and set up an encrypted RAID1 pool on the drives using the YaST partitioner. Upon completion, I checked the encrypted partition that was setup with the default options and found it was still using LUKS1 and PBKDF2 for the key derivation function.

Several months ago, Matthew Garrett published a post about a potential bypass out in the wild that may be affecting LUKS version 1 schemes.

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

Although I was already rsync-ing a few hundred gigabytes in data to it, I decided to upgrade following Matthew Garrett's post and very shortly had an up to date LUKS2 setup with the argon2id KDF.

Since there doesn't appear to be anything wrong with the setup, I would like to propose making LUKS2 with argon2id the default selection, in lieu of the difficulties with in-place upgrades, i.e. needing to boot from a device external to the encrypted drives.

Comment 1 Matthias Gerstner 2023-07-17 08:26:42 UTC

Thank you for bringing this to our attention.

SUSE security is aware of that article and the LUKS1 vs. LUKS2 and pbkdf2 vs.
argon2id situation.

As far I know, for full disk encryption, there have been a couple of hurdles
on the bootloader level (grub2) back then, blocking the switch to LUKS2. I
don't know how much this has improved by now.

I'm assigning this bug to our YaST2 maintainers for now, since you explicitly
mentioned the YaST2 partitioner resulting in LUKS1 headers.

Comment 2 Stefan Hundhammer 2023-07-17 09:12:19 UTC

Ancor, IIRC LUKS2 support has been on our to-do list for a while. Please check.

Comment 3 Ancor Gonzalez Sosa 2023-07-17 09:26:27 UTC

There are several reasons to stick to LUKS1 as default for the time being, although most of the problems are getting solved and we may reconsider making LUKS2 the default in a near future.

I usually use this comment as a summary of the reasons to stick to LUKS1 as default for now: https://bugzilla.suse.com/show_bug.cgi?id=1185291#c1

Making it even shorter:

- Lack of full support in Grub2
- Increase of the memory consumption

The first part (Grub2) is getting better and we may get full Grub2 support with Argon in the near future (but beware, in my experience Grub2 takes a veeeery long time to open a LUKS2 device).

You may skip that problem if you use a separate unencrypted /boot partition. But that's something we don't want to encourage in general (it has quite some drawbacks).

The second part is a bit more challenging, since we would need to explain why you suddenly need WAY MORE ram to perform an openSUSE installation if you choose encryption.

In any case, you can boot the installation process with the boot argument YAST_LUKS2_AVAILABLE to have the possibility of installing directly with LUKS2 as explained here https://github.com/yast/yast-storage-ng/pull/1245

That option have been there for almost a couple of years already, but there are still reasons for not making it the default.

Comment 4 Ancor Gonzalez Sosa 2023-07-17 09:30:26 UTC

Not exactly in our to-do list. Actually is somehow done for years (as explained at the end of my previous comment). Just conveniently "hidden" for good reasons (also explained in my previous comment).

As mentioned, we keep watching how the Grub2 support improves and we will make it available at Tumbleweed as soon as all the pieces are mature enough. For the time being, the status is correct.