-
Notifications
You must be signed in to change notification settings - Fork 106
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
Comments
(Note I'm not a clevis developer, just maintainer in Debian) Related, should clevis silently upgrade any older pbkdf usage? Somehow warn when it encouters one? |
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. |
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
But according to the man page of cryptsetup:
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. |
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.
The text was updated successfully, but these errors were encountered: