13 ms·

PSA: Upgrade your LUKS key derivation function

275 points by YakBizzarro 3y ago

orlp 3y ago
> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced. 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.
- mjg59 3y ago
  The presumption that 20 characters is any meaningful amount of entropy is based on the password actually being somewhat random, and there's no fundamental reason to believe that that's true. I tend towards brute forcing not being the most likely reason for this, but the indisputable reality is that any combination of weak passwords and PBKDF2 makes it plausible (if not necessarily likely) that an adversary with a sufficiently large hardware budget can break disk encryption.
  - deleted 3y ago
    [deleted]
  - aborsy 3y ago
    You don’t need to merely tend towards. You just can’t brute force a random 20 characters password of the type that he mentioned. Brute force is almost never used, even with half of entropy of such password. His password was intercepted, or was embarrassingly deterministic.
    - raverbashing 3y ago
      Or something like, notebook still had the keys in memory when it was recovered Though from this description it looks like they read the disk (trivial) but it's not sure if they actually pulled anything from it (at least it seems they didn't pull anything incriminating if I read it correctly).
    - mort96 3y ago
      I didn't see anyone mention a random 20 characters password. I saw 20 character password with symbols and upper and lower case. That might be 4 words strung together "correct horse battery staple" style.
    - mjg59 3y ago
      A stronger KDF would plausibly have protected him even if his password was embarrassingly deterministic.
      - stouset 3y ago
        Maybe. But probably not. If they were using a crib sheet to the point of only trying 1m attempts, this can be done in “days” with one CPU even if PBKDF2 is set to take one second each attempt on that CPU. A “better” KDF isn’t fundamentally going to change this. It’s just going to enforce stricter limits on any time-memory trade offs and require more memory. Neither of these are going to be meaningful differences when you’re cracking a single password for a single user with a crib sheet, unless you’re in the realm of billions or more guesses.
  - AlexCoventry 3y ago
    If the computer is suspended at the time it's seized, does it become easier to recover the FDE key from the computer's memory? Or is that encrypted with the user password, or something like that? (On stock ubuntu, say.)
    - mjg59 3y ago
      If you can dump the contents of memory then you have the key (after all, the CPU has to be able to encrypt and decrypt the material, so it has to be available).
      - zamnos 3y ago
        Pedantically, if there's an HSM/similar hardware in play, the CPU only asks for material to be encrypted/decrypted and doesn't have the key in system RAM to be able to do so itself. MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
      - ryan-c 3y ago
        Apparently it's possible to keep the key in the debug registers: https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
    - zamnos 3y ago
      If the DRAM is powered on at the time of seizure, recovering the key is eminently possible. If this is an issue for you, completely power off the laptop when transiting customs. https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
- segfaultbuserr 3y ago
  > so in the absence of any sort of opsec failures [...] The original sentence already came with this disclaimer.
  - wallmountedtv 3y ago
    Agreed. Annoyingly the author does split up a very core idea to the next paragraph: > and we should be transitioning to even more secure passphrases. [newline] Or does it? Let's go into what LUKS is doing in the first place. That sentence really should have been put into the introductory paragraph, instead of being the start of the 2nd.
    - eduction 3y ago
      Disagree, long paragraphs are more annoying than breaking up thoughts like this. I think it's reasonable to expect a reader to continue to the next paragraph, and corrosive to start writing for poor readers (distracted, skimming, etc - let people who do this bear the risk and consequences of their actions rather than changing writing to make this behavior less risky)
  - comboy 3y ago
    > absence of any sort of opsec failures There is no such thing.
- simoncion 3y ago
  a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec. b) The first two sentences of the next paragraph read: > Or does it? Let's go into what LUKS is doing in the first place Someone who doesn't know in detail the math of how this stuff works but _does_ know how to run tight opsec could very reasonably assume that now fairly long passwords can be brute-forced. That's like, the entire point of the article, innit? Describing how this almost certainly _wasn't_ an attack on the password, but almost certainly an attack on the mechanisms that use that password as an input to crypto.
  - mjg59 3y ago
    I don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
    - simoncion 3y ago
      > ...it's absolutely possible that the password was obtained through some other mechanism. +1 To be clear, the person I was replying to was all like "You _idiot_. Obviously the plaintext of the guy's password was in the possession of the attacker!", when the primary (if not the entire) _point_ of the article was to set up and answer the question "Well, what if it _wasn't_? Is it possible using default settings to brute-force a password?".
- ryan-c 3y ago
  The author clearly meant "cracked" rather than "brute forced". Password/passphrase cracking is done with sophisticated (and in cases like this one, likely tailored to the target) strategies that try more likely possibilities first. In such a scenario, "supposedly greater than 20 characters and [including] a mixture of cases, numbers, and punctuation" tells us little about how difficult it was to crack. For example, A11 y0ur b4s3 4r3 b3l0ng 70 u5! would be trivial to guess.
  - b112 3y ago
    They used chatGPT, trained on this user's emails, posts, data! (not many know this, but gpt secretly is french for Government Person Trained! The eventual goal, is that the gubberment will have mental maps of us all, and even use that to test meme class mental manipulation techniques on this simulated populous, to best determine those sweet words to control us. Rebels will become loyalists, anarchists state advocates, our very natures used to control us!)
- BeefWellington 3y ago
  While I agree in the specifics the overall message still stands IMO: Update your KDF going forward if you care about this kind of security.
- zokier 3y ago
  Making this bit mor concrete: luks1 uses pbkdf2 with sha1 and minimum iteration count of 1000 as far as I can tell. Looking at random hashcat benchmark for rtx 4090, the closest thing is about 20MH/s. If we assume attacker spends a month with 1000 gpus, they will have bruteforced 20e6×86400×30×1000 combinations. Log2 of that rounds up to 56 bits. https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
  - terom 3y ago
    You're underestimating the default PBKDF parameters used by LUKS1, `cryptsetup luksFormat` [1] benchmarks the `--pbkdf` function at runtime when configuring the keyslot, and the default iteration count is based on a target `--iter-time` [2], which is either 1s or 2s [3], unless overridden by the distro. I'm not entirely sure about the PRF (SHA1/256) used by LUKS1, it might be SHA-1 or SHA-256 [4]. For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U ( Q3'18) CPU, that appears to result in an iteration count on the order of 1-2M. Assuming those hashcat benchmark numbers scale linearly on the iteration count, you're down to about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256. Assuming 10kH/s, that drops you down to 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). OTOH it's easy to generate a 20-character password with far less entropy. [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://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
  - deleted 3y ago
    [deleted]
- mox1 3y ago
  Here's how it works: When the gov wants to crack a password, they gather all of your digital life (phone, computers, thumb drives, etc.) and basically run "strings" on all of the hard drives / data they have of you. They then use that strings output as input into the password cracking rig. They are happy to let it churn for months / years (because the case is working through the system). So its far more likely this individual hibernated his PC with the password in memory or reused the password elsewhere than it was cracked.
  - deleted 3y ago
    [deleted]
  - comboy 3y ago
    > They are happy to let it churn for months / years (because the case is working through the system). Is that the case? I would be surprised. I would assume success ratio does not change much by checking say 10^4 more combinations (it's either a simple combination of these strings and common prefxies/suffixes or if it's complex then the amount of combinations grows so fast that you are unlikely to get a hit)
    - sandworm101 3y ago
      No. Resources are always limited. Forensic investigators will not be running things on server farms for years. People who think such things really do not understand how many cases are "in the system" at any one time. Even for something relatively serious like CP, drug smuggling or lower-end terrorism, there are literally thousands of cases in-the-system. The server farms infrastructure (ie hiring cloud capacity) would be reserved for national security, foreign intelligence and stopping Magneto. The contents of your laptop are not worthy of such treatment.
  - realusername 3y ago
    Not sure how it's done in the US but an effort to crack it like this would happen only on very high profile cases in France which is not the case of this one. I'm betting on the second option, he reused the same password somewhere else or they just got lucky and seized the computer already unlocked
- corndoge 3y ago
  NSA agent spotted /s
- benlivengood 3y ago
  English has ~1 bit of entropy per character. Replacing a character with a similar symbol adds ~1.5 bits to that character (there aren't leetspeak substitutions for every letter, so I am being a little generous). Random symbol insertions between words adds ~5 bits per ~5 characters (10 numbers, their shift-codes, and the punctuation, average word length is ~5). If every letter of the password is randomly leetspeak that yields 50 bits. If symbols are inserted between each word (average of ~4 in 20 characters) that yields 70 bits, which is barely greater than the 68 bits of entropy per second equivalent of 300M TH/s
  - nickelpro 3y ago
    Please explain the math behind a 26 letter alphabet having 1 bit per character
    - dangerlibrary 3y ago
      I was also skeptical of this claim. It seems to come from Schneier's "Applied Cryptography" and assumes you are using whole words in the password. https://en.wikipedia.org/wiki/Entropy_(information_theory)#cite_ref-Schneier,_B_page_234_6-0 https://en.wikipedia.org/wiki/Entropy_(information_theory)#c... > English text, treated as a string of characters, has fairly low entropy, i.e., is fairly predictable. We can be fairly certain that, for example, 'e' will be far more common than 'z', that the combination 'qu' will be much more common than any other combination with a 'q' in it, and that the combination 'th' will be more common than 'z', 'q', or 'qu'. After the first few letters one can often guess the rest of the word. English text has between 0.6 and 1.3 bits of entropy per character of the message.[6]: 234
    - ravi-delia 3y ago
      Grammatical English is an extremely restricted subset of all strings of characters. You can actually see for yourself that it's in the ballpark of a bit by going to a book, covering up a line, reading the context, and trying to guess the next letter one at a time. I get it 3/4 times, and would probably be down to 1/2 if I had to do it the right way. Consider the difference in entropy between this totally randomly generated password, consisting of 4 words each from a pool of 100,000: Correct Horse Battery Staple 4lg(100000) = 33 And this one of the same length where each character was chosen from a bank of 68: VIW&jubiHZUgBrFA8PI9Vy1E(%G 28*lg(68) = 170
- dhx 3y ago
  A previous letter[1] supposedly from the same person stated that he was under surveillance before arrest, and thus "black-bag cryptanalysis"[2] is quite probable, particularly due to SDAT being a well resourced domestic spy agency. "the SDAT explains that they began to tail me and the other comrade (quickly exonerated) starting last January" [1] https://anarchistnews.org/content/update-letter-ivan-alocco https://anarchistnews.org/content/update-letter-ivan-alocco [2] https://en.wikipedia.org/wiki/Black-bag_cryptanalysis https://en.wikipedia.org/wiki/Black-bag_cryptanalysis
- deleted 3y ago
  [deleted]
- 8organicbits 3y ago
  > Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. Careful, that math assumes each character was chosen randomly, which isn't how people usually pick passwords. If the password contains words and patterns, then it was much weaker. "Passwordpasswordpass" matches those requirements, and is decidedly weak. But I agree, password reuse or other similar mistake seems likely.
- CodesInChaos 3y ago
  I don't follow your math. If we assume the cost of your password hash matches the cost of a bitcoin hash, I arrive at 2 * 10^6 years, not 4 * 10^39 years. 2^114/350e18/3600/24/365 = 1.9e6 Even 2^114 itself is only 2 * 10^34
  - codethief 3y ago
    Yeah, I'm not following that calculation either. Adding to that: > Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. Upper/lowercase are already 52 characters. If we add digits (0-9) we are already looking at log_2(62^20) = 119 bits of entropy. On that note: Let's assume the password were indeed purely random and had 119 genuine bits of entropy. If you're the attacker and your goal is to do 1000 (≃ 2^10) rounds of SHA1 for each of those 2^119 potential passwords, couldn't you then just try to brute-force the 128-bit key directly, since 119 + 10 >= 128? Put differently, wouldn't the statement "A fully random 20-character alphanumeric password has been brute-forced" amount to saying "AES-128 can be brute-forced"?
  - orlp 3y ago
    I... don't know what the hell happened. I was doing the calculation on mobile while on the move and I must've screwed up the parenthesis in the denominator. Embarrassing... Your calculation is correct. My point still stands (2 million years is plenty of time), but my number given was completely off. I can't edit it anymore though.
- acchow 3y ago
  > it would still take you 4 x 10^37 centuries. This calculation is for exhausting the entire search space, right? Not guessing at random (which would invoke the birthday paradox?). For block solving on Bitcoin, clients don't search the whole space. They try random values and check if it's right.
  - LodeOfCode 3y ago
    The birthday paradox only applies when you're trying to find any pair of inputs with the same output, because then the probability of success scales with the number of pairs ≈ guesses^2. If you're trying to find an input with a particular output (in this case one that results in the same key as their password), then on average you'll have to try half the search space (divided by the number of correct answers in the search space, but that should be one in this case) I'd assume the random guesses for bitcoin miners is because with a deterministic chunk of the search space you risk the possibility that someone else chose the same chunk and so already tried all the values you're trying
jeroenhd 3y ago
> Also, if you're using an encrypted /boot, stop now - very recent versions of grub2 support LUKS2, but they don't support argon2id, and this will render your system unbootable. 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.
- mjg59 3y ago
  argon2i is a strict improvement over PBKDF2, but sadly grub2 doesn't support any argon2 KDFs right now.
  - jeroenhd 3y ago
    I see, I must've misread. Thank you!
- struanr 3y ago
  It's a pain to set up, but you can use the EFISTUB[1] capabilities of the Linux kernel to make it boot itself. Initramfs is then capable of decrypting argon2id LUKS2 partitions. Since it requires keeping the kernel and other boot files on an unencrypted /boot partition, secure boot is a must to ensure the kernel hasn't been tampered with. Unfortunately, UEFI secure boot only supports signing one file, and so systemd-stub[2] can be used (doesn't require SystemD) to combine boot resources in a single PE binary, allowing them to be signed. I haven't followed it personally, but this[3] tutorial seems to go over the points I covered. [1]https://wiki.archlinux.org/title/EFISTUB https://wiki.archlinux.org/title/EFISTUB [2]https://www.freedesktop.org/software/systemd/man/systemd-stub.html https://www.freedesktop.org/software/systemd/man/systemd-stu... [3]https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ https://nwildner.com/posts/2020-07-04-secure-your-boot-proce...
  - jeroenhd 3y ago
deafpolygon 3y ago
Interesting article; 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?
- kevincox 3y ago
  IIUC the main benifit of Windows and macOS full disk encryption over Linux is that they will use a TPM to protect the key by default. This effectively prevents brute forcing of even very weak passwords at the expense of being unable to recover your data on a different computer. You can set up Linux to use the TPM which will be a good improvement. Other than that I believe that LUKS has good defaults.
  - jeroenhd 3y ago
    The TPM is a blessing and a curse. On the one hand, it protects you from having to remember any passwords and makes encryption available to almost anyone. On the other hand, someone who can steal your laptop may be able to dump the TPM keys by simply attaching probes and turning on your machine: https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/ https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/ I'm not sure about the situation on macOS, I think Apple's TPM is a bit more advanced than most PC alternatives. I don't think modern macs are vulnerable to the attack I linked above. Microsoft's Pluton chip may also be different, I can't find much about its physical security properties.
    - jsmith99 3y ago
deleted 3y ago
[deleted]
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.
Sesse__ 3y ago
Seemingly you cannot convert live to LUKS2; you'll need to unmount first. So that's a bit sad, and would probably make distro conversion a more complex. 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.
- Arnavion 3y ago
  >So that's a bit sad, and would probably make distro conversion a more complex. It shouldn't be. It can be done on next boot by the initramfs, before the real root etc are mounted.
  - Sesse__ 3y ago
    Yes, it means you need a reboot at the very least, and initramfs integration.
xaduha 3y ago
> Unfortunately it's not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken. 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.
- 1827162 3y ago
  In theory you could store it both offsite (using a hidden Micro SD card) and on your phone simultaneously, with a special key combination, e.g. pressing Vol Up + Vol Down + Power causing the phone to be rebooted, and the key erased from RAM... So in that case you would need to get the offsite copy, from GPS coordinates you have memorized, using a GPS receiver that is known not to leave any location information in it's EEPROM / Flash. Of course all this info has to be double checked to see if it actually works, and forensic tools run against the phone to be really really sure the key's not being written to Flash in any way, or remains in RAM after a reboot.
  - xaduha 3y ago
    Sure, knock yourself out if that's your thing. But what I meant was basically "power user" level devices, like what systemd-cryptenroll lists. So fido2, pkcs11 (smartcards and tokens) and tpm2. If you want to bury any of them in the woods, I guess you can. https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html https://www.freedesktop.org/software/systemd/man/systemd-cry...
- Vecr 3y ago
  That's not legal in the US though, at least the "destroy if shit hits the fan" part. The only legal solution is a secure password that's never written down or told to anyone else, ever. I really do mean ever, if the police have given up on you but they later find out that there was no incriminating evidence against you on the drive, they could charge you years later for obstructing the investigation. You and your lawyer need to come up with a glomar response strategy (i.e. "neither confirm nor deny") that there is anything on the drive that could incriminate you. You are not protected from providing the data/password if the contents incriminate people other than you and not you, so never say under oath that there's nothing incriminating on your drive, because they will make you prove it.
IAmLiterallyAB 3y ago
According to one of the experts on the panel of the Password Hashing Competition, Argon2 is actually weaker than bcrypt https://twitter.com/TerahashCorp/status/1155129705034653698 https://twitter.com/TerahashCorp/status/1155129705034653698 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.
- JeremyBanks 3y ago
  [dead]
- stevelacy 3y ago
  Farther comments in that thread indicate they are referring to PHF (password hashing function) not KDF (key derivation function). LUKS uses a KDF.
- upofadown 3y ago
  The issue as I understand it, is that if you want to limit the amount of time that the user has to wait to a second or less (a reasonable assumption) then you can't use all that much memory with Argon2. So you don't get a lot of memory hardness.
runeks 3y ago
> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation [...] 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.
- vlovich123 3y ago
  For a brute force attacker, how does a high entropy 20 character password vs a low entry 20 character password change discovery time? Even throwing in a random character in the middle would probably defeat any shortcuts, no?
  - im3w1l 3y ago
    There are 20 places to put the random character, and there are roughly 100 possible values, for a total of 2000 possibilities. Thus, assuming someone has knowledge of you using this trick, it corresponds to adding 11 bits of entropy. There are other similar tricks you could have been using instead, so there may be a few additional bits of security if they know you use some trick but not which one.
    - vlovich123 3y ago
      Right. But it requires some starting point for the password in the first place.
  - __MatrixMan__ 3y ago
    I think where this reasoning gets people in trouble is when their 20 char password was leaked by LinkedIn or some such and they've since mutated it by inserting the random character and think it's now secure. If the attacker uses a wordlist with the old password and a ruleslist with "throw in a random character", they're going to try the correct password long before they try a random 21 character string.
jagrsw 3y ago
A naive question: Are KDFs meant to improve the security of systems or merely preserve it? I was under the impression that the purpose of KDFs is twofold: 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. If the password is, say, 'abcd', then it could be converted into an AES-128 key in the following ways: 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. On paper, PBKDF2 is a better option because an attacker would need to perform the PBKDF2 computation before each decryption attempt, which would be time-consuming. Therefore, as long as the KDF is implemented correctly, it should offer better protection than the first option. 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!
- gruez 3y ago
  >they can precompute KDF outputs for each of those passwords and reuse them I'm not sure what is exactly meant by "precompute", but any sane implementation would use salts to prevent an attacker from precomputing common passwords so they can be used across multiple targets.
  - jagrsw 3y ago
    Ah.. that makes sense. I was sort-a stuck in the WiFi/WPA mode, where there are no explicit salts (I guess ssid names can be considered as such).
- bawolff 3y ago
  So there are different types of kdf's. For passwords, the goal of the kdf is to "stretch" the entropy by making the kdf function hard to compute. PBKDF2 basically works by hashing the password over and over again. Using pbkdf2 with 100,000 rounds, means bruteforcing is 100,000 times slower, because you have to hash each guess 100,000 times. Argon2 takes the idea further by being memory hard and resistent to parallelism. People briteforcing will use gpus to try lots of guesses in parallel (or asic if money is no object). These can handle pbkdf2 really fast but not argon2
throwawaaarrgh 3y ago
AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic without more research
- josephcsible 3y ago
  Your bootloader doesn't need to support it unless you insist on encrypting /boot.
  - deleted 3y ago
    [deleted]
  - usr1106 3y ago
    I tried encrypting /boot once, but grub2 is painfully slow to do the key derivation that Linux does in a couple of seconds. I understood vectorization makes the difference. The better approach seems to use dm-verity to make sure it's not been manipulated and store any secrets it might need in the TPM. Just for the design. I am not an anarchist or similar target, so I still live with just an encrypted rootfs which should be good enough against a random laptop thief.
    - Arnavion 3y ago
      Or use UEFI + Secure Boot instead if your motherboard lets you.
      - usr1106 3y ago
        Does that support verification of the initramfs? I have the feeling no it doesn't, but I am not sure. (Yes you can build the initramfs into the kernel. But I don't think that's commonly done. And UEFI implementations have undocumented size limits of what they can boot. So even if you are willing to spend the effort to configure that the image might not boot in the end.
        3y ago
ttyprintk 3y ago
Shufflecake has been posted recently: https://news.ycombinator.com/item?id=33586503 https://news.ycombinator.com/item?id=33586503 https://shufflecake.net/#news https://shufflecake.net/#news
- jzb 3y ago
  Would help if the comment expanded on what a Shufflecake is. For anyone else reading this, apparently it's "plausible deniability for multiple hidden filesystems on Linux." More: Shufflecake is made of two components: dm-sflc, which is a kernel module implementing the Shufflecake scheme as a device-mapper target for the Linux kernel, and shufflecake-userland, which is a command-line tool allowing the user to create and manage hidden volumes. The kernel module must be loaded before using the userland tool.
Brian_K_White 3y ago
Could one seperate the kdf from the disk? Actually, not have any kdf? 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.
- waste_monk 3y ago
  LUKS already supports keyfiles: https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Keyfiles https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... However I don't recall if the keyfile is then used to decrypt a header stored on disk to get the key that's actually used to en/decrypt the drive contents in the same way that passwords are.
  - riceart 3y ago
    Yes it is just another mechanism for header decryption. You can replace these keys just like a pass phrase.
  - tetha 3y ago
    To be specific, LUKS supports up to 8 slots. Slots can be used by different decryption mechanisms such as passwords (either typed in, or read from a keyfile), or something like clevis+tang to decrypt the disk on the correct network. Each of these slots can then decrypt the main key to decrypt the drive data. This is done for a few reasons. This allows you to change "your disk encryption password" - or rather, passwords used for password based slots - without re-encrypting the (arbitrarily large) disk (for an arbitrarily long time). You just change an encrypted master key for a different ciphertext of the same master key.
olabyne 3y ago
I'm french, and the source in french linked is not clear. The article is biased, the comments are saying it's from 2020, and I am pretty sure the french cyber teams would not throw a bunch of GPU to solve a password for a small case like his. 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 ?
- iforgotpassword 3y ago
  Agree, apart from a full-on keylogger, given the password was not super trivial to guess, is some other bad practice like unencrypted swap, though I hope there never was a distro that suggested that setup if you choose full disk encryption in the installer. If he was under surveillance a tampered with initramfs would be my guess.
1827162 3y ago
Maybe using two layers of encryption, so if one fails, then we at least have another one to be bruteforced as a backup? Also two implementations, from different operating systems (!), e.g. why not store the data encrypted on a server running OpenBSD, which is then encrypted again using Linux LUKS. So then both the OpenBSD and Linux implementations would have to fail, in order for the government to be able to decrypt it. Of course, using different, long passphrases for each.
- snowstormsun 3y ago
  That would impact r/w performance heavily.
  - 1827162 3y ago
    Yes, if used as a root filesystem. My computer is setup to have immutable read-only root filesystem, any changes go to RAM. Except for the home directory. There is no swap either. It shouldn't be a problem if you use it to store infrequently accessed material, e.g. the entire copy of Library Genesis (2.5 million ebooks). The double encryption will make sure absolutely that you cannot be prosecuted for possessing forbidden books (in countries where there is no mandatory key disclosure law). That way your reading habits are none of the government's business, period. As it should be.
12345hn6789 3y ago
The creator of LUKS has a few words around this on Reddit. This appears to be a non-story unless you're not practicing best proper password management 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_your_luks_key_derivation_function/jgpvsqc/ https://www.reddit.com/r/linux/comments/12q51ce/psa_upgrade_...
- blueflow 3y ago
  How do you even get a "Social Justice Warrior" badge on reddit?
  - steelbrain 3y ago
    In most subreddits, you can choose your own flair through reddit preferences. Once logged in, on `old.reddit.com`, search for "Show my flair on this subreddit. It looks like:" on the right side of the screen.
- 8organicbits 3y ago
  I always find this thinking fascinating. If you are using a suitably strong password, you don't need a KDF. And you _should_ be using a strong password, so we can hand wave any KDF related issues away. But people don't use strong passwords. We should know this by now. End users pick weak, predictable, non-random, short passwords. I've seen IT departments (who should know better) set weak passwords for users like "Company2023". A KDF can't save you if your password is extremely weak, but it can improve a mediocre password such that an attacker will give up before they succeed.
TacticalCoder 3y ago
> ... again and look for the PBKDF: line in each keyslot (pay attention only to the keyslots, ignore any references to pbkdf2 that come after the Digests: line). If the PBKDF is either "pbkdf2" or "argon2i" you should convert to argon2id All good here then (Debian Bookworm default LUKS install): cryptsetup luksDump /dev/... | grep PBKDF PBKDF: argon2id
dylan808hewitt 3y ago
[dead]
Crontab 3y ago
I think the mention that upgrading your distro doesn't automatically enable a better KDF for LUKS is a good point.
the-anarchist 3y ago
On a side note, regardless of whether and how big of an issue this is, from what I understand OpenZFS uses the same KDF: https://github.com/openzfs/zfs/issues/10764 https://github.com/openzfs/zfs/issues/10764 Gladly correct me in case I'm wrong.
thway15269037 3y ago
Totally random question that I was recently thinking about: can reuse of LUKS passphrases undermine security? 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?
- KingMachiavelli 3y ago
  The amount it could potentially "weaken" protection is likely negligible compared to how much it reduces the burden on the user (unless you consider the risk of having a single exposed password in plain text now means N machines are compromised instead of 1). Anyway, I'd assume that each LUKS key slot has a unique plaintext salt to prevent a single rainbow table being useful to attack every key slot - the attacker would still have to build a unique rainbow table for each. As long as this is the case then the time to bruteforce a password should be the same no matter how many keyslots or machines use the same password.
  - snowstormsun 3y ago
    Yeah there's a salt used
j0e1 3y ago
Obligatory xkcd: https://xkcd.com/538/ https://xkcd.com/538/
dathinab 3y ago
The problem with disk encryption on Linux isn't that it doesn't work. 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)
- _cenw 3y ago
  What's missing from cryptsetup? What would you like the state of the tooling to be? One big issue I see is that generating an initramfs is a very distro-dependent process and the glue to unlock your disk is not the most consistent. On the other hand, systemd now handles crypttab.
  - dathinab 3y ago
    Nothing from cryptsetup but tooling around it. Like automatically on-the-fly re-doing the key encryption/KDF when the default algorithm changes and is now more secure then the one used currently. or tooling for setting it up including TPM unlock, secure boot, hibernation etc. without needing to know all the config files and initramfs options you need to edit. (and lockdown mode + hibernation is currently also not at all supported and some distros default enabled lockdown mode when secure boot is used leading to a lot of headaches or "hibernation doesn't work claims" from users) Also standard schemas for desktop setups of the core system, including full disk encryption, raid(if needed), etc. But there is no tool and too many divergend approaches leading to no standard schema. And I mean sure, I can use a patched LTS kernel supporting both lock down and hybernation (at the cost of lockdown being slightly less secure) or disable lockdown mode. And then setup full disk encryption knowing how to evaluate the difference of FS (e.g. ZFS) encryption vs. LUKS and choose weather to do RAID=>LUKS=>LVM=>FS or LUKS=>LVM(with RAID)=>FS or LUKS=>FS(with subvolums and RAID) and maybe script some custom initrd mods to make that work well. Setup hibernation and how to setup secure boot with an efistub, systemd-boot or grub and why to do (or not do) either with custom platform keys.... and setup TPM encryption unlock and evaluate weather I want it or not etc. But man it's sooo annoying to do that and 100% not something I can expect anyone new to Linux to be able to get that anywhere close to right for their use-case.
brnt 3y ago
Am I the only one that chiefly uses FDE just so I only have to overwrite the LUKS header when I pass the drive on?
pshirshov 3y ago
There is the same (and ignored) problem in OpenZFS: https://github.com/openzfs/zfs/issues/14762 https://github.com/openzfs/zfs/issues/14762 Please vote there.
naruhodo 3y ago
Notwithstanding the comments here refuting the vulnerability, this is an informative and potentially useful article. I learned some stuff. FWIW, my fresh install of Fedora 38 uses argon2id as the KDF.
coppsilgold 3y ago
If he was under surveillance, all it takes is a microphone in the same room as his keyboard and it's over: <https://github.com/shoyo/acoustic-keylogger https://github.com/shoyo/acoustic-keylogger>

275 points by YakBizzarro 3y ago

orlp 3y ago

> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced. 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.

mjg59 3y ago
The presumption that 20 characters is any meaningful amount of entropy is based on the password actually being somewhat random, and there's no fundamental reason to believe that that's true. I tend towards brute forcing not being the most likely reason for this, but the indisputable reality is that any combination of weak passwords and PBKDF2 makes it plausible (if not necessarily likely) that an adversary with a sufficiently large hardware budget can break disk encryption.
- deleted 3y ago
  [deleted]
- aborsy 3y ago
  You don’t need to merely tend towards. You just can’t brute force a random 20 characters password of the type that he mentioned. Brute force is almost never used, even with half of entropy of such password. His password was intercepted, or was embarrassingly deterministic.
  - raverbashing 3y ago
    Or something like, notebook still had the keys in memory when it was recovered Though from this description it looks like they read the disk (trivial) but it's not sure if they actually pulled anything from it (at least it seems they didn't pull anything incriminating if I read it correctly).
  - mort96 3y ago
    I didn't see anyone mention a random 20 characters password. I saw 20 character password with symbols and upper and lower case. That might be 4 words strung together "correct horse battery staple" style.
  - mjg59 3y ago
    A stronger KDF would plausibly have protected him even if his password was embarrassingly deterministic.
    - stouset 3y ago
      Maybe. But probably not. If they were using a crib sheet to the point of only trying 1m attempts, this can be done in “days” with one CPU even if PBKDF2 is set to take one second each attempt on that CPU. A “better” KDF isn’t fundamentally going to change this. It’s just going to enforce stricter limits on any time-memory trade offs and require more memory. Neither of these are going to be meaningful differences when you’re cracking a single password for a single user with a crib sheet, unless you’re in the realm of billions or more guesses.
- AlexCoventry 3y ago
  If the computer is suspended at the time it's seized, does it become easier to recover the FDE key from the computer's memory? Or is that encrypted with the user password, or something like that? (On stock ubuntu, say.)
  - mjg59 3y ago
    If you can dump the contents of memory then you have the key (after all, the CPU has to be able to encrypt and decrypt the material, so it has to be available).
    - zamnos 3y ago
      Pedantically, if there's an HSM/similar hardware in play, the CPU only asks for material to be encrypted/decrypted and doesn't have the key in system RAM to be able to do so itself. MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
    - ryan-c 3y ago
      Apparently it's possible to keep the key in the debug registers: https://en.wikipedia.org/wiki/TRESOR https://en.wikipedia.org/wiki/TRESOR
  - zamnos 3y ago
    If the DRAM is powered on at the time of seizure, recovering the key is eminently possible. If this is an issue for you, completely power off the laptop when transiting customs. https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
segfaultbuserr 3y ago
> so in the absence of any sort of opsec failures [...] The original sentence already came with this disclaimer.
- wallmountedtv 3y ago
  Agreed. Annoyingly the author does split up a very core idea to the next paragraph: > and we should be transitioning to even more secure passphrases. [newline] Or does it? Let's go into what LUKS is doing in the first place. That sentence really should have been put into the introductory paragraph, instead of being the start of the 2nd.
  - eduction 3y ago
    Disagree, long paragraphs are more annoying than breaking up thoughts like this. I think it's reasonable to expect a reader to continue to the next paragraph, and corrosive to start writing for poor readers (distracted, skimming, etc - let people who do this bear the risk and consequences of their actions rather than changing writing to make this behavior less risky)
- comboy 3y ago
  > absence of any sort of opsec failures There is no such thing.
simoncion 3y ago
a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec. b) The first two sentences of the next paragraph read: > Or does it? Let's go into what LUKS is doing in the first place Someone who doesn't know in detail the math of how this stuff works but _does_ know how to run tight opsec could very reasonably assume that now fairly long passwords can be brute-forced. That's like, the entire point of the article, innit? Describing how this almost certainly _wasn't_ an attack on the password, but almost certainly an attack on the mechanisms that use that password as an input to crypto.
- mjg59 3y ago
  I don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
  - simoncion 3y ago
    > ...it's absolutely possible that the password was obtained through some other mechanism. +1 To be clear, the person I was replying to was all like "You _idiot_. Obviously the plaintext of the guy's password was in the possession of the attacker!", when the primary (if not the entire) _point_ of the article was to set up and answer the question "Well, what if it _wasn't_? Is it possible using default settings to brute-force a password?".
ryan-c 3y ago
The author clearly meant "cracked" rather than "brute forced". Password/passphrase cracking is done with sophisticated (and in cases like this one, likely tailored to the target) strategies that try more likely possibilities first. In such a scenario, "supposedly greater than 20 characters and [including] a mixture of cases, numbers, and punctuation" tells us little about how difficult it was to crack. For example, A11 y0ur b4s3 4r3 b3l0ng 70 u5! would be trivial to guess.
- b112 3y ago
  They used chatGPT, trained on this user's emails, posts, data! (not many know this, but gpt secretly is french for Government Person Trained! The eventual goal, is that the gubberment will have mental maps of us all, and even use that to test meme class mental manipulation techniques on this simulated populous, to best determine those sweet words to control us. Rebels will become loyalists, anarchists state advocates, our very natures used to control us!)
BeefWellington 3y ago
While I agree in the specifics the overall message still stands IMO: Update your KDF going forward if you care about this kind of security.
zokier 3y ago
Making this bit mor concrete: luks1 uses pbkdf2 with sha1 and minimum iteration count of 1000 as far as I can tell. Looking at random hashcat benchmark for rtx 4090, the closest thing is about 20MH/s. If we assume attacker spends a month with 1000 gpus, they will have bruteforced 20e6×86400×30×1000 combinations. Log2 of that rounds up to 56 bits. https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb422222fd#file-rtx_4090_v6-2-6-benchmark-L1238 https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
- terom 3y ago
  You're underestimating the default PBKDF parameters used by LUKS1, `cryptsetup luksFormat` [1] benchmarks the `--pbkdf` function at runtime when configuring the keyslot, and the default iteration count is based on a target `--iter-time` [2], which is either 1s or 2s [3], unless overridden by the distro. I'm not entirely sure about the PRF (SHA1/256) used by LUKS1, it might be SHA-1 or SHA-256 [4]. For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U ( Q3'18) CPU, that appears to result in an iteration count on the order of 1-2M. Assuming those hashcat benchmark numbers scale linearly on the iteration count, you're down to about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256. Assuming 10kH/s, that drops you down to 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). OTOH it's easy to generate a 20-character password with far less entropy. [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://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
- deleted 3y ago
  [deleted]
mox1 3y ago
Here's how it works: When the gov wants to crack a password, they gather all of your digital life (phone, computers, thumb drives, etc.) and basically run "strings" on all of the hard drives / data they have of you. They then use that strings output as input into the password cracking rig. They are happy to let it churn for months / years (because the case is working through the system). So its far more likely this individual hibernated his PC with the password in memory or reused the password elsewhere than it was cracked.
- deleted 3y ago
  [deleted]
- comboy 3y ago
  > They are happy to let it churn for months / years (because the case is working through the system). Is that the case? I would be surprised. I would assume success ratio does not change much by checking say 10^4 more combinations (it's either a simple combination of these strings and common prefxies/suffixes or if it's complex then the amount of combinations grows so fast that you are unlikely to get a hit)
  - sandworm101 3y ago
    No. Resources are always limited. Forensic investigators will not be running things on server farms for years. People who think such things really do not understand how many cases are "in the system" at any one time. Even for something relatively serious like CP, drug smuggling or lower-end terrorism, there are literally thousands of cases in-the-system. The server farms infrastructure (ie hiring cloud capacity) would be reserved for national security, foreign intelligence and stopping Magneto. The contents of your laptop are not worthy of such treatment.
- realusername 3y ago
  Not sure how it's done in the US but an effort to crack it like this would happen only on very high profile cases in France which is not the case of this one. I'm betting on the second option, he reused the same password somewhere else or they just got lucky and seized the computer already unlocked
corndoge 3y ago
NSA agent spotted /s
benlivengood 3y ago
English has ~1 bit of entropy per character. Replacing a character with a similar symbol adds ~1.5 bits to that character (there aren't leetspeak substitutions for every letter, so I am being a little generous). Random symbol insertions between words adds ~5 bits per ~5 characters (10 numbers, their shift-codes, and the punctuation, average word length is ~5). If every letter of the password is randomly leetspeak that yields 50 bits. If symbols are inserted between each word (average of ~4 in 20 characters) that yields 70 bits, which is barely greater than the 68 bits of entropy per second equivalent of 300M TH/s
- nickelpro 3y ago
  Please explain the math behind a 26 letter alphabet having 1 bit per character
  - dangerlibrary 3y ago
    I was also skeptical of this claim. It seems to come from Schneier's "Applied Cryptography" and assumes you are using whole words in the password. https://en.wikipedia.org/wiki/Entropy_(information_theory)#cite_ref-Schneier,_B_page_234_6-0 https://en.wikipedia.org/wiki/Entropy_(information_theory)#c... > English text, treated as a string of characters, has fairly low entropy, i.e., is fairly predictable. We can be fairly certain that, for example, 'e' will be far more common than 'z', that the combination 'qu' will be much more common than any other combination with a 'q' in it, and that the combination 'th' will be more common than 'z', 'q', or 'qu'. After the first few letters one can often guess the rest of the word. English text has between 0.6 and 1.3 bits of entropy per character of the message.[6]: 234
  - ravi-delia 3y ago
    Grammatical English is an extremely restricted subset of all strings of characters. You can actually see for yourself that it's in the ballpark of a bit by going to a book, covering up a line, reading the context, and trying to guess the next letter one at a time. I get it 3/4 times, and would probably be down to 1/2 if I had to do it the right way. Consider the difference in entropy between this totally randomly generated password, consisting of 4 words each from a pool of 100,000: Correct Horse Battery Staple 4lg(100000) = 33 And this one of the same length where each character was chosen from a bank of 68: VIW&jubiHZUgBrFA8PI9Vy1E(%G 28*lg(68) = 170
dhx 3y ago
A previous letter[1] supposedly from the same person stated that he was under surveillance before arrest, and thus "black-bag cryptanalysis"[2] is quite probable, particularly due to SDAT being a well resourced domestic spy agency. "the SDAT explains that they began to tail me and the other comrade (quickly exonerated) starting last January" [1] https://anarchistnews.org/content/update-letter-ivan-alocco https://anarchistnews.org/content/update-letter-ivan-alocco [2] https://en.wikipedia.org/wiki/Black-bag_cryptanalysis https://en.wikipedia.org/wiki/Black-bag_cryptanalysis
deleted 3y ago
[deleted]
8organicbits 3y ago
> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. Careful, that math assumes each character was chosen randomly, which isn't how people usually pick passwords. If the password contains words and patterns, then it was much weaker. "Passwordpasswordpass" matches those requirements, and is decidedly weak. But I agree, password reuse or other similar mistake seems likely.
CodesInChaos 3y ago
I don't follow your math. If we assume the cost of your password hash matches the cost of a bitcoin hash, I arrive at 2 * 10^6 years, not 4 * 10^39 years. 2^114/350e18/3600/24/365 = 1.9e6 Even 2^114 itself is only 2 * 10^34
- codethief 3y ago
  Yeah, I'm not following that calculation either. Adding to that: > Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. Upper/lowercase are already 52 characters. If we add digits (0-9) we are already looking at log_2(62^20) = 119 bits of entropy. On that note: Let's assume the password were indeed purely random and had 119 genuine bits of entropy. If you're the attacker and your goal is to do 1000 (≃ 2^10) rounds of SHA1 for each of those 2^119 potential passwords, couldn't you then just try to brute-force the 128-bit key directly, since 119 + 10 >= 128? Put differently, wouldn't the statement "A fully random 20-character alphanumeric password has been brute-forced" amount to saying "AES-128 can be brute-forced"?
- orlp 3y ago
  I... don't know what the hell happened. I was doing the calculation on mobile while on the move and I must've screwed up the parenthesis in the denominator. Embarrassing... Your calculation is correct. My point still stands (2 million years is plenty of time), but my number given was completely off. I can't edit it anymore though.
acchow 3y ago
> it would still take you 4 x 10^37 centuries. This calculation is for exhausting the entire search space, right? Not guessing at random (which would invoke the birthday paradox?). For block solving on Bitcoin, clients don't search the whole space. They try random values and check if it's right.
- LodeOfCode 3y ago
  The birthday paradox only applies when you're trying to find any pair of inputs with the same output, because then the probability of success scales with the number of pairs ≈ guesses^2. If you're trying to find an input with a particular output (in this case one that results in the same key as their password), then on average you'll have to try half the search space (divided by the number of correct answers in the search space, but that should be one in this case) I'd assume the random guesses for bitcoin miners is because with a deterministic chunk of the search space you risk the possibility that someone else chose the same chunk and so already tried all the values you're trying

jeroenhd 3y ago

> Also, if you're using an encrypted /boot, stop now - very recent versions of grub2 support LUKS2, but they don't support argon2id, and this will render your system unbootable. 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.

mjg59 3y ago
argon2i is a strict improvement over PBKDF2, but sadly grub2 doesn't support any argon2 KDFs right now.
- jeroenhd 3y ago
  I see, I must've misread. Thank you!
struanr 3y ago
It's a pain to set up, but you can use the EFISTUB[1] capabilities of the Linux kernel to make it boot itself. Initramfs is then capable of decrypting argon2id LUKS2 partitions. Since it requires keeping the kernel and other boot files on an unencrypted /boot partition, secure boot is a must to ensure the kernel hasn't been tampered with. Unfortunately, UEFI secure boot only supports signing one file, and so systemd-stub[2] can be used (doesn't require SystemD) to combine boot resources in a single PE binary, allowing them to be signed. I haven't followed it personally, but this[3] tutorial seems to go over the points I covered. [1]https://wiki.archlinux.org/title/EFISTUB https://wiki.archlinux.org/title/EFISTUB [2]https://www.freedesktop.org/software/systemd/man/systemd-stub.html https://www.freedesktop.org/software/systemd/man/systemd-stu... [3]https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ https://nwildner.com/posts/2020-07-04-secure-your-boot-proce...
- jeroenhd 3y ago

deafpolygon 3y ago

Interesting article; 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?

kevincox 3y ago
IIUC the main benifit of Windows and macOS full disk encryption over Linux is that they will use a TPM to protect the key by default. This effectively prevents brute forcing of even very weak passwords at the expense of being unable to recover your data on a different computer. You can set up Linux to use the TPM which will be a good improvement. Other than that I believe that LUKS has good defaults.
- jeroenhd 3y ago
  The TPM is a blessing and a curse. On the one hand, it protects you from having to remember any passwords and makes encryption available to almost anyone. On the other hand, someone who can steal your laptop may be able to dump the TPM keys by simply attaching probes and turning on your machine: https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/ https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/ I'm not sure about the situation on macOS, I think Apple's TPM is a bit more advanced than most PC alternatives. I don't think modern macs are vulnerable to the attack I linked above. Microsoft's Pluton chip may also be different, I can't find much about its physical security properties.
  - jsmith99 3y ago

deleted 3y ago

[deleted]

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.

Sesse__ 3y ago

Seemingly you cannot convert live to LUKS2; you'll need to unmount first. So that's a bit sad, and would probably make distro conversion a more complex. 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.

Arnavion 3y ago
>So that's a bit sad, and would probably make distro conversion a more complex. It shouldn't be. It can be done on next boot by the initramfs, before the real root etc are mounted.
- Sesse__ 3y ago
  Yes, it means you need a reboot at the very least, and initramfs integration.

xaduha 3y ago

> Unfortunately it's not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken. 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.

1827162 3y ago
In theory you could store it both offsite (using a hidden Micro SD card) and on your phone simultaneously, with a special key combination, e.g. pressing Vol Up + Vol Down + Power causing the phone to be rebooted, and the key erased from RAM... So in that case you would need to get the offsite copy, from GPS coordinates you have memorized, using a GPS receiver that is known not to leave any location information in it's EEPROM / Flash. Of course all this info has to be double checked to see if it actually works, and forensic tools run against the phone to be really really sure the key's not being written to Flash in any way, or remains in RAM after a reboot.
- xaduha 3y ago
  Sure, knock yourself out if that's your thing. But what I meant was basically "power user" level devices, like what systemd-cryptenroll lists. So fido2, pkcs11 (smartcards and tokens) and tpm2. If you want to bury any of them in the woods, I guess you can. https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html https://www.freedesktop.org/software/systemd/man/systemd-cry...
Vecr 3y ago
That's not legal in the US though, at least the "destroy if shit hits the fan" part. The only legal solution is a secure password that's never written down or told to anyone else, ever. I really do mean ever, if the police have given up on you but they later find out that there was no incriminating evidence against you on the drive, they could charge you years later for obstructing the investigation. You and your lawyer need to come up with a glomar response strategy (i.e. "neither confirm nor deny") that there is anything on the drive that could incriminate you. You are not protected from providing the data/password if the contents incriminate people other than you and not you, so never say under oath that there's nothing incriminating on your drive, because they will make you prove it.

IAmLiterallyAB 3y ago

According to one of the experts on the panel of the Password Hashing Competition, Argon2 is actually weaker than bcrypt https://twitter.com/TerahashCorp/status/1155129705034653698 https://twitter.com/TerahashCorp/status/1155129705034653698 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.

JeremyBanks 3y ago
[dead]
stevelacy 3y ago
Farther comments in that thread indicate they are referring to PHF (password hashing function) not KDF (key derivation function). LUKS uses a KDF.
upofadown 3y ago
The issue as I understand it, is that if you want to limit the amount of time that the user has to wait to a second or less (a reasonable assumption) then you can't use all that much memory with Argon2. So you don't get a lot of memory hardness.

runeks 3y ago

> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation [...] 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.

vlovich123 3y ago
For a brute force attacker, how does a high entropy 20 character password vs a low entry 20 character password change discovery time? Even throwing in a random character in the middle would probably defeat any shortcuts, no?
- im3w1l 3y ago
  There are 20 places to put the random character, and there are roughly 100 possible values, for a total of 2000 possibilities. Thus, assuming someone has knowledge of you using this trick, it corresponds to adding 11 bits of entropy. There are other similar tricks you could have been using instead, so there may be a few additional bits of security if they know you use some trick but not which one.
  - vlovich123 3y ago
    Right. But it requires some starting point for the password in the first place.
- __MatrixMan__ 3y ago
  I think where this reasoning gets people in trouble is when their 20 char password was leaked by LinkedIn or some such and they've since mutated it by inserting the random character and think it's now secure. If the attacker uses a wordlist with the old password and a ruleslist with "throw in a random character", they're going to try the correct password long before they try a random 21 character string.

jagrsw 3y ago

A naive question: Are KDFs meant to improve the security of systems or merely preserve it? I was under the impression that the purpose of KDFs is twofold: 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. If the password is, say, 'abcd', then it could be converted into an AES-128 key in the following ways: 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. On paper, PBKDF2 is a better option because an attacker would need to perform the PBKDF2 computation before each decryption attempt, which would be time-consuming. Therefore, as long as the KDF is implemented correctly, it should offer better protection than the first option. 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!

gruez 3y ago
>they can precompute KDF outputs for each of those passwords and reuse them I'm not sure what is exactly meant by "precompute", but any sane implementation would use salts to prevent an attacker from precomputing common passwords so they can be used across multiple targets.
- jagrsw 3y ago
  Ah.. that makes sense. I was sort-a stuck in the WiFi/WPA mode, where there are no explicit salts (I guess ssid names can be considered as such).
bawolff 3y ago
So there are different types of kdf's. For passwords, the goal of the kdf is to "stretch" the entropy by making the kdf function hard to compute. PBKDF2 basically works by hashing the password over and over again. Using pbkdf2 with 100,000 rounds, means bruteforcing is 100,000 times slower, because you have to hash each guess 100,000 times. Argon2 takes the idea further by being memory hard and resistent to parallelism. People briteforcing will use gpus to try lots of guesses in parallel (or asic if money is no object). These can handle pbkdf2 really fast but not argon2

throwawaaarrgh 3y ago

AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic without more research

josephcsible 3y ago
Your bootloader doesn't need to support it unless you insist on encrypting /boot.
- deleted 3y ago
  [deleted]
- usr1106 3y ago
  I tried encrypting /boot once, but grub2 is painfully slow to do the key derivation that Linux does in a couple of seconds. I understood vectorization makes the difference. The better approach seems to use dm-verity to make sure it's not been manipulated and store any secrets it might need in the TPM. Just for the design. I am not an anarchist or similar target, so I still live with just an encrypted rootfs which should be good enough against a random laptop thief.
  - Arnavion 3y ago
    Or use UEFI + Secure Boot instead if your motherboard lets you.
    - usr1106 3y ago
      Does that support verification of the initramfs? I have the feeling no it doesn't, but I am not sure. (Yes you can build the initramfs into the kernel. But I don't think that's commonly done. And UEFI implementations have undocumented size limits of what they can boot. So even if you are willing to spend the effort to configure that the image might not boot in the end.
      - 3y ago

ttyprintk 3y ago

Shufflecake has been posted recently: https://news.ycombinator.com/item?id=33586503 https://news.ycombinator.com/item?id=33586503 https://shufflecake.net/#news https://shufflecake.net/#news

jzb 3y ago
Would help if the comment expanded on what a Shufflecake is. For anyone else reading this, apparently it's "plausible deniability for multiple hidden filesystems on Linux." More: Shufflecake is made of two components: dm-sflc, which is a kernel module implementing the Shufflecake scheme as a device-mapper target for the Linux kernel, and shufflecake-userland, which is a command-line tool allowing the user to create and manage hidden volumes. The kernel module must be loaded before using the userland tool.

Brian_K_White 3y ago

Could one seperate the kdf from the disk? Actually, not have any kdf? 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.

waste_monk 3y ago
LUKS already supports keyfiles: https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Keyfiles https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... However I don't recall if the keyfile is then used to decrypt a header stored on disk to get the key that's actually used to en/decrypt the drive contents in the same way that passwords are.
- riceart 3y ago
  Yes it is just another mechanism for header decryption. You can replace these keys just like a pass phrase.
- tetha 3y ago
  To be specific, LUKS supports up to 8 slots. Slots can be used by different decryption mechanisms such as passwords (either typed in, or read from a keyfile), or something like clevis+tang to decrypt the disk on the correct network. Each of these slots can then decrypt the main key to decrypt the drive data. This is done for a few reasons. This allows you to change "your disk encryption password" - or rather, passwords used for password based slots - without re-encrypting the (arbitrarily large) disk (for an arbitrarily long time). You just change an encrypted master key for a different ciphertext of the same master key.

olabyne 3y ago

I'm french, and the source in french linked is not clear. The article is biased, the comments are saying it's from 2020, and I am pretty sure the french cyber teams would not throw a bunch of GPU to solve a password for a small case like his. 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 ?

iforgotpassword 3y ago
Agree, apart from a full-on keylogger, given the password was not super trivial to guess, is some other bad practice like unencrypted swap, though I hope there never was a distro that suggested that setup if you choose full disk encryption in the installer. If he was under surveillance a tampered with initramfs would be my guess.

1827162 3y ago

Maybe using two layers of encryption, so if one fails, then we at least have another one to be bruteforced as a backup? Also two implementations, from different operating systems (!), e.g. why not store the data encrypted on a server running OpenBSD, which is then encrypted again using Linux LUKS. So then both the OpenBSD and Linux implementations would have to fail, in order for the government to be able to decrypt it. Of course, using different, long passphrases for each.

snowstormsun 3y ago
That would impact r/w performance heavily.
- 1827162 3y ago
  Yes, if used as a root filesystem. My computer is setup to have immutable read-only root filesystem, any changes go to RAM. Except for the home directory. There is no swap either. It shouldn't be a problem if you use it to store infrequently accessed material, e.g. the entire copy of Library Genesis (2.5 million ebooks). The double encryption will make sure absolutely that you cannot be prosecuted for possessing forbidden books (in countries where there is no mandatory key disclosure law). That way your reading habits are none of the government's business, period. As it should be.

12345hn6789 3y ago

The creator of LUKS has a few words around this on Reddit. This appears to be a non-story unless you're not practicing best proper password management 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_your_luks_key_derivation_function/jgpvsqc/ https://www.reddit.com/r/linux/comments/12q51ce/psa_upgrade_...

blueflow 3y ago
How do you even get a "Social Justice Warrior" badge on reddit?
- steelbrain 3y ago
  In most subreddits, you can choose your own flair through reddit preferences. Once logged in, on `old.reddit.com`, search for "Show my flair on this subreddit. It looks like:" on the right side of the screen.
8organicbits 3y ago
I always find this thinking fascinating. If you are using a suitably strong password, you don't need a KDF. And you _should_ be using a strong password, so we can hand wave any KDF related issues away. But people don't use strong passwords. We should know this by now. End users pick weak, predictable, non-random, short passwords. I've seen IT departments (who should know better) set weak passwords for users like "Company2023". A KDF can't save you if your password is extremely weak, but it can improve a mediocre password such that an attacker will give up before they succeed.

TacticalCoder 3y ago

> ... again and look for the PBKDF: line in each keyslot (pay attention only to the keyslots, ignore any references to pbkdf2 that come after the Digests: line). If the PBKDF is either "pbkdf2" or "argon2i" you should convert to argon2id All good here then (Debian Bookworm default LUKS install): cryptsetup luksDump /dev/... | grep PBKDF PBKDF: argon2id

dylan808hewitt 3y ago

[dead]

Crontab 3y ago

I think the mention that upgrading your distro doesn't automatically enable a better KDF for LUKS is a good point.

the-anarchist 3y ago

On a side note, regardless of whether and how big of an issue this is, from what I understand OpenZFS uses the same KDF: https://github.com/openzfs/zfs/issues/10764 https://github.com/openzfs/zfs/issues/10764 Gladly correct me in case I'm wrong.

thway15269037 3y ago

Totally random question that I was recently thinking about: can reuse of LUKS passphrases undermine security? 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?

KingMachiavelli 3y ago
The amount it could potentially "weaken" protection is likely negligible compared to how much it reduces the burden on the user (unless you consider the risk of having a single exposed password in plain text now means N machines are compromised instead of 1). Anyway, I'd assume that each LUKS key slot has a unique plaintext salt to prevent a single rainbow table being useful to attack every key slot - the attacker would still have to build a unique rainbow table for each. As long as this is the case then the time to bruteforce a password should be the same no matter how many keyslots or machines use the same password.
- snowstormsun 3y ago
  Yeah there's a salt used

j0e1 3y ago

Obligatory xkcd: https://xkcd.com/538/ https://xkcd.com/538/

dathinab 3y ago

The problem with disk encryption on Linux isn't that it doesn't work. 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)

_cenw 3y ago
What's missing from cryptsetup? What would you like the state of the tooling to be? One big issue I see is that generating an initramfs is a very distro-dependent process and the glue to unlock your disk is not the most consistent. On the other hand, systemd now handles crypttab.
- dathinab 3y ago
  Nothing from cryptsetup but tooling around it. Like automatically on-the-fly re-doing the key encryption/KDF when the default algorithm changes and is now more secure then the one used currently. or tooling for setting it up including TPM unlock, secure boot, hibernation etc. without needing to know all the config files and initramfs options you need to edit. (and lockdown mode + hibernation is currently also not at all supported and some distros default enabled lockdown mode when secure boot is used leading to a lot of headaches or "hibernation doesn't work claims" from users) Also standard schemas for desktop setups of the core system, including full disk encryption, raid(if needed), etc. But there is no tool and too many divergend approaches leading to no standard schema. And I mean sure, I can use a patched LTS kernel supporting both lock down and hybernation (at the cost of lockdown being slightly less secure) or disable lockdown mode. And then setup full disk encryption knowing how to evaluate the difference of FS (e.g. ZFS) encryption vs. LUKS and choose weather to do RAID=>LUKS=>LVM=>FS or LUKS=>LVM(with RAID)=>FS or LUKS=>FS(with subvolums and RAID) and maybe script some custom initrd mods to make that work well. Setup hibernation and how to setup secure boot with an efistub, systemd-boot or grub and why to do (or not do) either with custom platform keys.... and setup TPM encryption unlock and evaluate weather I want it or not etc. But man it's sooo annoying to do that and 100% not something I can expect anyone new to Linux to be able to get that anywhere close to right for their use-case.

brnt 3y ago

Am I the only one that chiefly uses FDE just so I only have to overwrite the LUKS header when I pass the drive on?

pshirshov 3y ago

There is the same (and ignored) problem in OpenZFS: https://github.com/openzfs/zfs/issues/14762 https://github.com/openzfs/zfs/issues/14762 Please vote there.

naruhodo 3y ago

Notwithstanding the comments here refuting the vulnerability, this is an informative and potentially useful article. I learned some stuff. FWIW, my fresh install of Fedora 38 uses argon2id as the KDF.

coppsilgold 3y ago

If he was under surveillance, all it takes is a microphone in the same room as his keyboard and it's over: <https://github.com/shoyo/acoustic-keylogger https://github.com/shoyo/acoustic-keylogger>