ZFS doesn't support argon2id and uses PBKDF2 instead for native encryption

There has been a case where someone had their disk decrypted by brute forcing because they were using PBKDF2 for LUKS mjg59 | PSA: upgrade your LUKS key derivation function

1 Like

I just skimmed the post so correct me if I’m wrong but…

Ubuntu 18.04 used the LUKS1 header format, and the only KDF supported in this format is PBKDF2. This is not a memory expensive KDF, and so is vulnerable to GPU-based attacks. But even so, systems using the LUKS2 header format used to default to argon2i, again not a memory expensive KDFwhich is memory strong, but not designed to be resistant to GPU attack (thanks to the comments pointing out my misunderstanding here). New versions default to argon2id, which is. You want to be using argon2id.

Doesn’t this imply current versions of Ubuntu (and presumably most other distros) default to argon2id? It would seem the PSA should be directed towards people who’ve upgraded from older versions:

What makes this worse is that distributions generally don’t update this in any way. If you installed your system and it gave you pbkdf2 as your KDF, you’re probably still using pbkdf2 even if you’ve upgraded to a system that would use argon2id on a fresh install.

GRUB has the same limitation in terms of argon2id:

Unless you use something custom like the “grub-improved-luks2-git” in Arch:

For a lot of people, I’d say that using PBKDF2 for LUKS2 is quite good enough, of course that if you have the option to use argon2id is better. If you are using one of the two your are already doing more than 90% of the Linux base probably. It is that type of situation that you have a car that is good enough and now there is a new shine car around with some advanced features and you start to despise your good enough car but in the end it may still be very efficient for most tasks.

2 Likes

If it’s vulnerable to brute force attacks even with strong passwords, why would PBKDF2 be good enough? Do you mean if you increase the number of iterations or something?

In the link shared by @jerm in the comment embedded you can find some nice evidence of this:

“with LUKS1 with PBKDF2 and a password consisting of 13 random upper and lower case letters and digits, an attack with the current computing power of the entire Bitcoin network (assuming that it remains at this level and there is no further technical progress) would take 77 years. Assuming that the available computing power doubles every 24 months, it would be 10-12 years.”

This seems quite reasonable for general consumer level in my opinion but not sure if I need to understand this a little bit better.

Yeah, for sure increasing the number of interaction or interval can definitely add more security to the peace of mind.

I’ve recommended 16+ and max memory (4GB) for years:

sudo cryptsetup luksConvertKey /dev/nvme0n1p3 --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4 --pbkdf-force-iterations=16

the default auto detection can easily end up being only 512mb with 4 iterations depending on your system

2 Likes