Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to choose other PBKDF than pbkdf2 #406

Open
glance- opened this issue Apr 20, 2023 · 3 comments
Open

Ability to choose other PBKDF than pbkdf2 #406

glance- opened this issue Apr 20, 2023 · 3 comments

Comments

@glance-
Copy link

glance- commented Apr 20, 2023

According to https://mjg59.dreamwidth.org/66429.html one should use argon2id as PBKDF rather than pbkdf2.

As I read:
https://github.com/latchset/clevis/blob/master/src/luks/clevis-luks-common-functions.in#L789

Clevis hard codes the pbkdf to pbkdf2, which according to above mentioned summary is vulnerable to a gpu based brute force attack.

Clevis should provide a way of picking a different PBKDF than pbkdf2 , ex, argon2id.

@cbiedl
Copy link

cbiedl commented Apr 20, 2023

(Note I'm not a clevis developer, just maintainer in Debian)
While I agree we have an issue here, that change was deliberately introduced in 7159630 some 18 months ago, addressing issues related to the memory consumption. Blindly reverting this - it seems earlier just the existing pbkdf value was re-used - will bring another problem.
So this requires more consideration, and possibly it was a good idea to look for similar discussions in the cryptsetup project: Make two(?) Gbyte memory a mandatory requirement, or should there be a mode for smaller systems with fewer ressources?

Related, should clevis silently upgrade any older pbkdf usage? Somehow warn when it encouters one?

@dmfs
Copy link

dmfs commented Apr 21, 2023

I'm by no means a security expert so takes this with a big grain of salt.

I think you have no reason to worry.

One main point of a password based key derivation function (pbkdf) is to protect weak (e.g. human generated) passphrases. Clevis generates a random key of (up to) 256 bit length. AFAIK, this is considered a strong key by today's standards.

The average user generated passphrase probably has no more than about 140 bits of entropy. So the Clevis key still takes an attacker about 2^110 (~10^33) times more time to brute force than a user generated passphrase.

@ghost
Copy link

ghost commented Oct 6, 2023

I also would like to use argon2id. Even if pbkdf2 should be sufficient in most cases, argon2id is just stronger.

Assuming, the kdf will not be changed upstream and I do not want to compile clevis myself, I was wondering if it was possible to change the kdf after the keyslot has been created by clevis. According to the link in the first post, this should be possible via

sudo cryptsetup luksConvertKey /dev/whatever --pbkdf argon2id

But according to the man page of cryptsetup:

The passphrase for keyslot to be converted must be supplied interactively or via --key-file.

Hence the question: How can the luks key created by clevis be recovered?

Edit: The best option would probably still be to make the kdf a parameter so that people with low memory can use pbkdf2 if they want to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants