latchset / clevis

Automated Encryption Framework
GNU General Public License v3.0
834 stars 99 forks source link

Ability to choose other PBKDF than pbkdf2 #406

Open glance- opened 1 year ago

glance- commented 1 year ago

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 commented 1 year ago

(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 715963075 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 commented 1 year ago

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 commented 9 months ago

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.