4 ms·

What I find weird is that not many talk about one of the parameter to PBKDF2, c, the number of iterations desired. Someone here mentioned it a few days ago: ju

What I find weird is that not many talk about one of the parameter to PBKDF2, c, the number of iterations desired. Someone here mentioned it a few days ago: just make decryption fast enough to be acceptable for you but still a big multiplier compared to the default. What do people care, when unlocking their SSD, if it takes 3ms or 300ms to unlock the SSD at boot? I mean: attacker shall have a bazillion RAM and a trizillion GPUs... Fine. I augment the number of iterations by 1024, there, it's brute-force attacking cost just rose by 1024. (I'm not sure that person was attacked by bruteforce but I'm surprised it's always left out... And now I've got friends sending me that picture with "time needed to brute-force a password if it has x, y or z characters" and I don't know what to answer except that "it's more complicated than that picture which circulates everywhere)

doodlesdev 3y ago
The problem is PBKDF2 isn't as memory intensive, it's really easy to parallelize on a modern GPU thus making it a much worse PBKDF than Argon2id. Increasing iteration count is just a bandaid over this problem, you also need to have control over memory usage.
- zokier 3y ago
  Sure argon2 is better, but high iteration count pbkdf2 is still a lot of work to crack, and afaik the work still scales linearly with iteration count. Lets do bit of reality check here. I checked my 14 year old laptop luks setup and it has iteration count set to 462093 and it unlocks near instantly. Looking at hashcat benchmark results for PBKDF2-HMAC-SHA1[1] I'd estimate that for that iteration count it'd do about 47 kH/s. Running a full year with 100000 gpus of that perf means about 2^47 hashes bruteforced (=log2(47e3×100e3×86400×365)). Considering that I'm using maybe 70ish bit secret there, I'm not exactly concerned. I still should upgrade to have better margin, but there is no reason to panic; I'd consider it still practically uncrackable with current level of tech. [1] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
  - giantrobot 3y ago
    I think it's worthwhile to be concerned about hashing ASICs used in crypto mining. They're stupidly cheap and outperform GPUs for hashing. They don't have much in the way of memory so they're not useful in memory-hard problems.
  - doodlesdev 3y ago
    No, I agree with you on that matter, there is no reason to panic, I was just trying to explain why Argon2id should receive preference over PBKDF2. Something else I forgot and a sibling comment touched upon is that hashing algorithms that are not memory-intensive can often be run on ASICS and that's when things can get a bit uglier. Overall, this kind of thing really just depends on your threat model and the data you're trying to protect, let's not forget https://xkcd.com/538/ https://xkcd.com/538/ lol
upofadown 3y ago
The linked ElcomSoft article claims that LUKS does does that sort of thing by default: >LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key.
terom 3y ago
Yes, `cryptsetup luksFormat` selects the LUKS1 key slot pbkdf iteration count parameter at runtime by benchmarking against a target `--iter-time` [1] [2], which is either 1s or 2s depending on version [3]. For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U (Q3'18) CPU, that seems to result in an iteration count on the order of 1.8M. Assuming the RTX 4090 hashcat benchmarks [4] scale linearly on the iteration count, that's about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256. In terms of brute-force vs password entropy, that would give you roughly 45 bits of entropy for 1k gpu-months, or ~250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits). Worryingly close enough to make replacing the KDF a relevant concern, but still enough to make this story about brute-forcing a random 20-character password somewhat implausible, unless the password was far weaker than implied. [1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.8.html https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Iteration_time https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...

doodlesdev 3y ago

The problem is PBKDF2 isn't as memory intensive, it's really easy to parallelize on a modern GPU thus making it a much worse PBKDF than Argon2id. Increasing iteration count is just a bandaid over this problem, you also need to have control over memory usage.

zokier 3y ago
Sure argon2 is better, but high iteration count pbkdf2 is still a lot of work to crack, and afaik the work still scales linearly with iteration count. Lets do bit of reality check here. I checked my 14 year old laptop luks setup and it has iteration count set to 462093 and it unlocks near instantly. Looking at hashcat benchmark results for PBKDF2-HMAC-SHA1[1] I'd estimate that for that iteration count it'd do about 47 kH/s. Running a full year with 100000 gpus of that perf means about 2^47 hashes bruteforced (=log2(47e3×100e3×86400×365)). Considering that I'm using maybe 70ish bit secret there, I'm not exactly concerned. I still should upgrade to have better margin, but there is no reason to panic; I'd consider it still practically uncrackable with current level of tech. [1] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
- giantrobot 3y ago
  I think it's worthwhile to be concerned about hashing ASICs used in crypto mining. They're stupidly cheap and outperform GPUs for hashing. They don't have much in the way of memory so they're not useful in memory-hard problems.
- doodlesdev 3y ago
  No, I agree with you on that matter, there is no reason to panic, I was just trying to explain why Argon2id should receive preference over PBKDF2. Something else I forgot and a sibling comment touched upon is that hashing algorithms that are not memory-intensive can often be run on ASICS and that's when things can get a bit uglier. Overall, this kind of thing really just depends on your threat model and the data you're trying to protect, let's not forget https://xkcd.com/538/ https://xkcd.com/538/ lol

upofadown 3y ago

The linked ElcomSoft article claims that LUKS does does that sort of thing by default: >LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key.

terom 3y ago

Yes, `cryptsetup luksFormat` selects the LUKS1 key slot pbkdf iteration count parameter at runtime by benchmarking against a target `--iter-time` [1] [2], which is either 1s or 2s depending on version [3]. For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U (Q3'18) CPU, that seems to result in an iteration count on the order of 1.8M. Assuming the RTX 4090 hashcat benchmarks [4] scale linearly on the iteration count, that's about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256. In terms of brute-force vs password entropy, that would give you roughly 45 bits of entropy for 1k gpu-months, or ~250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits). Worryingly close enough to make replacing the KDF a relevant concern, but still enough to make this story about brute-forcing a random 20-character password somewhat implausible, unless the password was far weaker than implied. [1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.8.html https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Iteration_time https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...