5 ms·

I would highly recommend setting the key derivation parameters to take as long as you can tolerate. For example: --pbkdf argon2id --pbkdf-memory 41943

by ryan-c 3y ago

I would highly recommend setting the key derivation parameters to take as long as you can tolerate. For example: --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 4 --iter-time 60000 (4GiB memory cost - it's specified in KiB, 4 threads (maximum), 60 seconds target time) If you have an especially powerful machine, it seems to be able to use a significant fraction of total memory, so you can do something like this: $ time cryptsetup benchmark --pbkdf argon2id --pbkdf-memory 100663296 --pbkdf-parallel 4 --iter-time 150000 # Tests are approximate using memory only (no storage IO). argon2id 7 iterations, 100663296 memory, 4 parallel threads (CPUs) for 256-bit key (requested 150000 ms time) real 2m36.822s user 9m50.221s sys 0m18.921s Possibly an excellent trade-off for a desktop you rarely reboot.

ryan-c 3y ago
Also, if you want to be a troll, add some additional passwords (LUKS2 supports multiple) with weak KDF parameters that are generated like this: head -c48 /dev/urandom | base64 It won't add much to your unlock time, but anyone trying to crack your disk will probably try the "easier" ones first.
- mr42023 3y ago
  If you've got a TPM to leverage, this is essentially actually what systemd-cryptenroll --tpm2* does. Generate a large, cryptographically-secure key and pair it with PBKDF2 with 1000 iterations. Seal that random value in the TPM with optional PIN. If used, the PIN itself can just be your prior disk encryption passphrase, and now you have the same PW entropy as before with additional protection against PCR modifications and brute-forcing via the TPM
- __MatrixMan__ 3y ago
  Doesn't that just give the attacker more targets to hit? I know that under normal circumstances you can just write off the wildly improbable case of a hash collision, but when you're up against an army of GPU's I'm not sure I'd want to risk the possibility that `aaa` (or some other brute force candidate) collides with whatever urandom spit out that day.
  - sowbug 3y ago
    Each of those red-herring passphrases is 384 bits. Enough said.
  - ryan-c 3y ago
    Even under abnormal circumstances, it can be written off. You're more likely to win several lottery jackpots in a row than to be bitten by that.
- rwmj 3y ago
  That's quite a funny idea. LUKS2 really should do this by default when creating the empty slots when the disk is initialized first time. The used slots will be overwritten by passphrases, but these other slots would be indistingishable and would waste the attacker's time.
  - Arnavion 3y ago
    It would make typoing the password annoying for legitimate users too, so it wouldn't be good to enable it by default.
    - ryan-c 3y ago
      With weak (fast) parameters for the KDFs on the decoy passwords, I don't see how it would be annoying?
orlp 3y ago
Adding four randomly generated characters a-z to your password adds a factor of 456976x to the bruteforce time required. A password that is derived in 1 millisecond with these characters appended takes longer to crack than a password that is derived in 7 minutes without those characters appended. "setting the key derivation parameters to take as long as you can tolerate" gives a false sense of security. Because it's taking a minute to log in it must be secure, right? In reality just making your password slightly stronger is far more effective security-wise.
- ryan-c 3y ago
  Adding extra random characters to the end of the passphrase requires effort from the user, key derivation only requires them to wait. Ideally, one should use a strong passphrase with strong key derivation parameters. You're free to make whatever security trade-offs you like, but don't presume they make sense for everyone.
  - deleted 3y ago
    [deleted]

by ryan-c 3y ago

ryan-c 3y ago

Also, if you want to be a troll, add some additional passwords (LUKS2 supports multiple) with weak KDF parameters that are generated like this: head -c48 /dev/urandom | base64 It won't add much to your unlock time, but anyone trying to crack your disk will probably try the "easier" ones first.

mr42023 3y ago
If you've got a TPM to leverage, this is essentially actually what systemd-cryptenroll --tpm2* does. Generate a large, cryptographically-secure key and pair it with PBKDF2 with 1000 iterations. Seal that random value in the TPM with optional PIN. If used, the PIN itself can just be your prior disk encryption passphrase, and now you have the same PW entropy as before with additional protection against PCR modifications and brute-forcing via the TPM
__MatrixMan__ 3y ago
Doesn't that just give the attacker more targets to hit? I know that under normal circumstances you can just write off the wildly improbable case of a hash collision, but when you're up against an army of GPU's I'm not sure I'd want to risk the possibility that `aaa` (or some other brute force candidate) collides with whatever urandom spit out that day.
- sowbug 3y ago
  Each of those red-herring passphrases is 384 bits. Enough said.
- ryan-c 3y ago
  Even under abnormal circumstances, it can be written off. You're more likely to win several lottery jackpots in a row than to be bitten by that.
rwmj 3y ago
That's quite a funny idea. LUKS2 really should do this by default when creating the empty slots when the disk is initialized first time. The used slots will be overwritten by passphrases, but these other slots would be indistingishable and would waste the attacker's time.
- Arnavion 3y ago
  It would make typoing the password annoying for legitimate users too, so it wouldn't be good to enable it by default.
  - ryan-c 3y ago
    With weak (fast) parameters for the KDFs on the decoy passwords, I don't see how it would be annoying?

orlp 3y ago

Adding four randomly generated characters a-z to your password adds a factor of 456976x to the bruteforce time required. A password that is derived in 1 millisecond with these characters appended takes longer to crack than a password that is derived in 7 minutes without those characters appended. "setting the key derivation parameters to take as long as you can tolerate" gives a false sense of security. Because it's taking a minute to log in it must be secure, right? In reality just making your password slightly stronger is far more effective security-wise.

ryan-c 3y ago
Adding extra random characters to the end of the passphrase requires effort from the user, key derivation only requires them to wait. Ideally, one should use a strong passphrase with strong key derivation parameters. You're free to make whatever security trade-offs you like, but don't presume they make sense for everyone.
- deleted 3y ago
  [deleted]