by YakBizzarro on 4/18/23, 8:33 AM with 186 comments
by orlp on 4/18/23, 9:57 AM
Sorry but there's no world in which this password was bruteforced in 2023, even if they were using just SHA1 as their PBKDF. Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. To put this in perspective, if you could use the entire global bitcoin mining equipment (estimated at 350 million terahashes / second) right now without modification to bruteforce this one password it would still take you 4 x 10^37 centuries. The author of the article failed to do this basic math.
The dude reused passwords, got keylogged, powned some other way, was coerced, had something unencrypted, or something else happened. But his password did not get bruteforced.
by 12345hn6789 on 4/18/23, 3:07 PM
Clemens Fruhwirth here. I am the inventor of LUKS.
A random keyboard typable character gives you around 6 bits of entropy. 20 of those give you 120 bits of entropy. Even without a KDF, brute-forcing this key space is infeasible with today's hardware. Even with PBKDF2, a 13-character password should be enough to keep your data secure for your lifetime.[1]
It is much more likely that there was some security failure in the linked case other than PBKDF2. That said, I support the upgrade to Argon2.
[1] In my thesis on LUKS, Chapter 5.3 Passwords from entropy weak sources anticipates the creation of specialized hardware for breaking PBKDF2. The "13 characters should be enough" advice is found on Page 86, Table 5.4, top left cell. It gives a 78-bit recommendation (=13 characters) in the worst-case scenario, which is Moore's law continues to double the attacker speed every 2 years.
[0]https://www.reddit.com/r/linux/comments/12q51ce/psa_upgrade_...
by olabyne on 4/18/23, 2:15 PM
Who knows if he used a non encrypted swap partition ? A leaked online account ? The guy complaining here doesn't make it very clear if its encryption was broken either, he's just over-interpreting the police reports by mentionnning some emails ?
by jagrsw on 4/18/23, 12:27 PM
a) Preserve entropy of the password material (up to a limit - size of the input to the next stage)
b) Derive a fixed-length output suitable for use as an input for the next cryptographic stage.
1). Use 'a', 'b', 'c', 'd' as the first four bytes of the AES-128 key (32 bits) in ASCII form, and then pad the rest with zeros or ones or use some other well-known pattern (based on convention). This method preserves entropy but is not computationally expensive.
2). Use a KDF like PBKDF2.
However, if we're talking about an attacker has the resources to brute-force a large number of generated passwords (based on real-world use or derived from hand-crafted or ML-derived criteria), they can precompute KDF outputs for each of those passwords and reuse them. This would make the second scenario (using PBKDF2) as easy or hard as the first one (using simple padding).
PS: Not a cryptographer, please don't shoot!
by Brian_K_White on 4/18/23, 1:50 PM
Where the disk only has a fully secure huge random key, not generated by a kdf but supplied whole by usb or something.
Protecting that external component is a problem, but it's a seperate problem, and having a copy of the drive, and everything else in your posession, and all the ram and gpus in aws doesn't get you into that drive.
The external part doesn't have to be a thumb drive right on your person. It could be stored anywhere on-line and/or on paper, and you just know where it is and how to get it.
You might have to re-create some kind of thumb drive for conveient use, but you could also intentionally lose/destroy it any time and not have it on your person during travel or sitting in a drawer at home. You would only recreate it when & where you decided it was safe to.
I guess that's what tpm aims to do. It's physically on-board but not accessible, as long as you trust the chip maker.
Obviously I've spent about 5 entire minutes thinking about this. Please excuse.
by ryan-c on 4/18/23, 11:11 AM
For example:
--pbkdf argon2id
--pbkdf-memory 4194304
--pbkdf-parallel 4
--iter-time 60000
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
by runeks on 4/18/23, 12:21 PM
It doesn't really matter what kinds of characters your passphrase of 20 characters contains. What matters is how much entropy it contains, ie. whether it was generated randomly.
A random 20-character password containing just lower case English letters would still take more time to break than the age of the universe assuming one billion guesses per second.
by xaduha on 4/18/23, 11:54 AM
Yes, it's not practical to type that. So don't, stop using passwords for this as a main way to unlock it. You can add a password as a backup key, but the main one shouldn't include a keyboard. There are plenty of hardware options other than TPM that you can destroy if shit hits the fan.
by TacticalCoder on 4/18/23, 3:23 PM
All good here then (Debian Bookworm default LUKS install):
cryptsetup luksDump /dev/... | grep PBKDF
PBKDF: argon2idby deafpolygon on 4/18/23, 10:41 AM
I kind of want to ask a question here since I'm likely to run into my betters on this topic. How does macOS / Windows 11 / Linux stack up to each other in terms of full-disk encryption?
What's the simplest approach to ensuring that my data isn't as easily decrypted, and to protect myself? (I'm aware of other vectors like via Internet/browsing, etc, but I'm concerned also about the physical security of my data).
Is macOS disk encryption pretty good all things considering? I see Windows 11 requires a compatible configuration to enable it for Home edition, or a Pro license. (Why?)
I've setup LUKS, created my keyphrases and all of that before on Fedora. But I'll be honest, I don't know how effective the defaults are and whether I'm doing the correct thing. I also worried about losing access to my data if the disk or LUKS volume became corrupted.
Any advice or tips for me?
by ttyprintk on 4/18/23, 1:44 PM
by dathinab on 4/18/23, 6:37 PM
It's that while there is well working reliable core tooling, all the tooling around it, especially more higher level tooling is, well, not so grate and often incomplete.
This makes it a "expert" topic even through there is no fundamental need for it being such a topic.
At least for full disk encryption (encrypted `/`), `systemd-homed` is it's own, different, can of worms ;=) (and given that it add no benefit for a single user non-server laptop system with properly done full disk encryption I didn't use it yet, so I can't give feedback)
by throwawaaarrgh on 4/18/23, 1:23 PM
by IAmLiterallyAB on 4/18/23, 11:57 AM
I'm not an expert, but I'm really curious to hear more. It's especially weird given I've heard nothing but good things about Argon2 otherwise.
by thway15269037 on 4/18/23, 5:46 PM
Yeah, yeah, I know, reusing passwords/passphrases is bad and all, but consider only this use case: you have PC and have a laptop. Or you have a PC where you accidentally written your passphrase twice in two different slots (if that's possible). Does that weaken protection? Or it would not help attacker in any way provided you kept passphrase safe?
by Sesse__ on 4/18/23, 11:13 AM
But I think maybe you can increase the number of PBKDF2 iterations? I heard at some point that the default in very old versions of cryptsetup, you'd always get 1000 iterations (which is very low), but nowadays, I think it's based on timing the CPU you're creating the volume on.
by the-anarchist on 4/18/23, 5:37 PM
Gladly correct me in case I'm wrong.
by jeroenhd on 4/18/23, 10:27 AM
That's rather unfortunate. My knowledge of key derivation algorithms is a bit out of date, so can someone confirm that if an old volume is still using PKBDF2 headers you can still get some benefits upgrading to argon2i? Or are both of them equally useless at this point in time?
I've always wondered why the key algorithm depends on the speed of the CPU, this makes cheaper devices or handheld devices less secure for a second or two of extra boot time.
by pshirshov on 4/18/23, 8:29 PM
Please vote there.
by 1827162 on 4/18/23, 2:16 PM
by coppsilgold on 4/19/23, 5:47 AM
by naruhodo on 4/19/23, 2:53 AM
FWIW, my fresh install of Fedora 38 uses argon2id as the KDF.
by Crontab on 4/18/23, 3:56 PM
by brnt on 4/18/23, 8:03 PM
by j0e1 on 4/18/23, 6:35 PM