10 ms·

Cracking LUKS/dm-crypt passphrases

105 points by dvaun 7y ago

loeg 7y ago
Maybe it goes without saying, but for this to work, your password must be bad to begin with. Or at least, the article does not point to any significant design weaknesses in LUKS; it instead documents a variety of ways to get passphrase-encrypted secrets into existing tools for bruteforcing passwords. The article suggests it is about backup or data recovery, but I think it is probably more interesting to people in the business of digital forensics.
- polack 7y ago
  I agree with you, but I actually used the brute force for data recovery. I had a NAS with a 22 characters passphrase that I had up and running for years and eventually forgot the password to. When I set it up I practiced the password enough times that I was sure I would never forget it so I never stored it anywhere. After years of never rebooting the NAS parts of the passphrase eventually got blurry and when I was about to move I realized I couldn't remember it anymore. I didn't really have anything of high value stored on it, but it kind of became a pet project to try to "crack" into it again. Together with Hashcat and the extracted header I eventually managed to brute force it after a couple of weeks :)
  - CaptainMarvel 7y ago
    How did you brute force 22 characters? Did you somehow use your fuzzy memory of the password to help?
    - polack 7y ago
      Yes, sorry I was unclear about that. I knew multiple parts of it, but not what position the segments would go into. I had also mixed the passphrase up with another old obsolete one, so I had too many of these segments (back then I broke up the passphrases into blocks of 4 chars in my head) to fit in. There was also a couple of chars that I was uncertain about so those got "fully" brute forced. The worst part about the process was that it was hard to create rules for Hashcat to generate all different possibilities for the passphrase with all the information I knew about it baked in.
      - MawKKe 7y ago
        So.. nothing to do with LUKS?
        lucb1e 7y ago
        Just because luks isn't bad doesn't mean you can't use cracking tools to recover data when you forgot half the password, only have surveillance footage of the password being typed, have a bad password, etc. Since the article doesn't document any (new) luks weaknesses, none of the comments will be about luks being insecure.
      - MayeulC 7y ago
        I've been in the same situation multiple times. I don't recall a case where the data was of critical importance, so I could get away with it, but using the parts of the passphrase I knew in a combined bruteforce/dictionary attack definitely crossed my mind. Do you have some links to reference material on how to achieve that?
  - DyslexicAtheist 7y ago
    one way to solve the problem of memorizing (long passwords) is to use something like this: to avoid forgetting it use a string of words that make sense to your brain[1] but are unlikely to be encountered in the wild (in any texts). Example passphrase: "My hamster kicks soapy homework with smurf locks like a tandem at 45 o clock!" Then use this to generate a hash which can never be remembered in itself, and is unlikely to be brute-forced: $ echo -n "My hamster kicks soapy homework with smurf locks like a tandem at 45 o clock!" | sha512sum 7364796a1ad957d7c524165aa2fec2501eaa59e6bd8380bad3252504cdb8592018e30ae2fff1b2c2295e6da7a7f47f52ef1c0e3010c054598d76fe0c6d64bac6 - this way there is no need to remember the hash itself as long as you know how to recreate the hash (+ have the tooling present like sha512sum). In case you want to change the hash without having to remember a new passphrase just twiddle with the input string (by changing one character only) to get a totally new hash. If you're on a multi-tenant machine this is probably dangerous since running `ps` might show other users on the system the input string when you run the command. Not an issue with single user systems. In case you want to avoid the command being recorded in your shell history file you can prefix the whole command with a blank (space). Benefit of this is you get a pretty long hash that is impossible to brute-force and extremely hard to remember, which makes it really useful as a master-password.
    - Thorrez 7y ago
      One weakness of this is that sha512sum is a fast hash, ideally it would use a slow and memory hard-hash. Of course if your password is strong enough it doesn't matter. An example attack would be an attacker compromises the password database of a site you use, and that site doesn't hash passwords. Next the attacker cracks that hash, which requires your password to be somewhat weak, but is aided by you not using a slow hash. Next the attacker uses that cracked master password variation to crack your LUKS setup. While LUKS uses a slow memory-hard hash, the attacker doesn't need to do many attempts, because the password is a small variation of the password the attacker already knows.
      - zaarn 7y ago
        That would matter less if you use the hash as a password as the comment suggests; in that case it matters what the website below in the stack uses.
- Nokinside 7y ago
  Ofthentimes password is there to discourage. Information is sensitive but it's more important that you can get it even if you lose the password than keeping it secret. And sometimes you have a really good long password that decays in your memory until you can't get it right. After few hundred tries you must either give up or start cracking it systematically using parts that you remember.
  - mirimir 7y ago
    Yeah, been there. I have a few LUKS encrypted backup drives with forgotten passphrases. And in many cases, I've also forgotten what's on them. At least one has a fortune in Bitcoin, I suspect. But the passphrases are all ~50 or more characters.
- badrabbit 7y ago
  Could luks have been designed to use memory-hard hash funcrions to prevent brute forcing like this?
  - aaronmdjones 7y ago
    LUKS2 (the current version) does support Argon2 with up to 4 GiB of memory and 4 threads.
  - loeg 7y ago
    Per the article, LUKS is designed to use 2 seconds of PBKDF2 iterations, which is going to be vastly greater than the 2016 NIST recommended minimum of 10,000 iterations. So brute forcing is already quite slow, although not as memory hard as newer KDFs like scrypt/argon. It's not a bad design for 2004. As the sibling commenter and article point out, LUKS2 defaults to argon2i with 2 seconds of iteration time and 1GB of memory, 4 threads.
    - mrb 7y ago
      Actually LUKS uses 1 second of iterations, last time I checked, and according to the code: https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/libcryptsetup.h#L323 https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/lib...
      - loeg 7y ago
        Nope. That's a comment on a tangentially related function declaration; it happens to be inaccurate. Here is where the default is actually specified (2000 ms): https://gitlab.com/cryptsetup/cryptsetup/blob/master/configure.ac#L579 https://gitlab.com/cryptsetup/cryptsetup/blob/master/configu... CS_NUM_WITH([luks1-iter-time], [PBKDF2 iteration time for LUKS1 (in ms)], [2000]) See also https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/utils_pbkdf.c#L27 https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/uti... . const struct crypt_pbkdf_type default_pbkdf2 = { .type = CRYPT_KDF_PBKDF2, .hash = DEFAULT_LUKS1_HASH, .time_ms = DEFAULT_LUKS1_ITER_TIME };
- mirimir 7y ago
  Yes. Or people into illegal digital forensics. But for any of them, they can copy the relevant section to crack, and bruteforce massively in parallel. So I use ~50 character passphrases for LUKS. None are written or stored. All from my memory. Still, with enough fast processors working in parallel, that could probably be cracked within a few years. But then, given my age, there's a fair chance that I'd be dead before they managed it.
  - bostik 7y ago
    > So I use ~50 character passphrases for LUKS. [...] with enough fast processors working in parallel, that could probably be cracked Let's do some napkin math. I'm going to make a blind assumption that you are a native English speaker, which gives us entropy estimate of ~1 bit per character.[0] Let's be generous and assume your passphrase has 51 bits of entropy, which makes the following numbers nice and round. To exhaustively search through half the passphrase space, the cracking rig will need to try 2^{50} =~ 10^{15} times. [50 * ln(2) =~ 50 * 0.301] The default master password hashing scheme in LUKS is PBKDF2, and for modern setups, argon2. The article throws around a few hashing speed ballparks, but depending on the setup we're talking about on the order of 1000 hashing attempts per second, per core. (Yes yes, the OP has figures with the argon2 numbers at about half that - I'm being very conservative here.) So, for a single LUKS passphrase crack we're talking, on average, of about 10^{12} core-seconds. A core-year is about 3 * 10^{7} seconds. So, with a single core the brute-force would take, on average, about 10^{5} years. As such... in order to break one of your passphrases, an attacker would need to dedicate 10k core-years of CPU time. That's a lot of hardware and cooling, but it's certainly not infeasible. You would need to be pretty attractive/dangerous/high-value target for anyone to spend that kind of money, though. Then the final step, threat modeling. For a normal techie, a passphrase like yours should be safe enough. For someone with access to material such as top hedge fund secrets, or into dangerous and politically juicy activities, attacking their passphrase is well within reach of a determined and well funded organisation. 0: https://people.seas.harvard.edu/~jones/cscie129/papers/stanford_info_paper/entropy_of_english_9.htm https://people.seas.harvard.edu/~jones/cscie129/papers/stanf...
    - mirimir 7y ago
luksflux 7y ago
Good luck with people like me. As ypu know, luks per default allows over 8 megabytes of key, so, i just make a dev/urandom file that is up to the byte filling the top default keysize, which means a password of over 8 million characters, of which none or very few at best are found via the keyboard. I use at the minimum 8 million chars on all my luks devices. And I've set the key stretching to take above 15 mins to unlock, even with the right password, so good luck with John the ripper.
- newnewpdro 7y ago
  Where are you storing that? Is it then encrypted with a passphrase?
- unixhero 7y ago
  How do you modify the to e required between attempts?
  - unixhero 7y ago
    *time
- dharmab 7y ago
  Either the key is stored unencrypted on a physical device, which can likely be seized by an attackers who has access to the ciphertext, or is encrypted with a passphrase. This isn't doing anything the master key and passphrase isn't already doing. (The key you input is not the key used to encrypt the data.)
  - acqq 7y ago
    The advantage of using a long key (generated randomly) is that bruteforcing of the material protected with the key is impossible, which does matter in some scenarios: specifically, if one trusts the container format, knows that the container will be accessible to the potential attackers who can try to brute force it, but also knows that the rest (the long key used) won’t be accessible to the said attackers. Which can be a reasonable scenario. Whoever uses a password manager should use reasonably long keys generated randomly. The real problem, like always, is key management. And knowing what is “overkill” for a given scenario, i.e. where reasonability ends. 8 MB is really something that should have some additional reasons than just protection from brute forcing the key.
Aardwolf 7y ago
I admit I didn't read the entire article, I've been reading only the text around instances of argon and PBKDF, but: can someone ELI5 how they do 882 hashes per second if PBKDF2 is set up to take 2 seconds, for example? What's so broken about PBKDF2 that they get a > 1000x speedup?
- simcop2387 7y ago
  It's trivially parrallelizable so I suspect that they're doing it on a gpu or something like that.
  - wongarsu 7y ago
    Which is a known "vulnerability" of PBKDF2. In any modern setup you are better served by Argon2 (or if that's not available at least scrypt). CPU time is cheap to parallelize, memory bandwidth is much harder to scale.
    - Aardwolf 7y ago
      There must, in addition to memory, be other things that are hard to parallelize on GPU's, right? How would 64-bit integer division do on a GPU? The GPU does not have 1000x more transistors than a CPU, it can't be 1000x faster for everything, right? The annoying thing is LUKS1 only supports PBKDF2, but LUKS2 comes with a JSON parser, and no full support everywhere yet
      - simcop2387 7y ago
        The best targets are stuff that is data dependant for behavior and memory size for current gpus. Larger number sizes will help but maybe not as much as you think, since those work well for FPGA or asic devices. Data dependency helps because it can kill cache behavior and branch prediction which are key features for fast speed on fpga and gpu devices. Combined with memory size which limits the number of possible attempts on devices thats where the protection comes from. N.B. sorry for typos, have a cat in the way
      - 7y ago
quotemstr 7y ago
Sure. That's why I wish I could do LUKS authentication via TPM, which can do hardware rate-limiting. Is this kind of setup possible these days?
- anon9001 7y ago
  You can use a yubikey to do it. It can work in challenge/response mode, so the yubikey is required to unlock the device. That's good for laptops. You can also use a private gpg key and an gpg-encrypted keyfile. Yubikey can store gpg keys (with attestation if you want), and you can enable both yubikey access and gpg in initramfs. That's good for servers if you pair it with initramfs sshd. TPM is kind of broken, as I understand it, so I didn't even bother looking into it. There's really no reason I can't carry my keys on my physical keychain, so I don't see a need for TPM. I can also put a USB stick on my keychain and use that to boot. That way even if an attacker has physical access to the hardware, it would be require some really advanced firmware/microcode hackery to compromise the machine.
  - quotemstr 7y ago
    How is TPM broken? I'm curious.
    - anon9001 7y ago
      Some TPM chips are vulnerable to key dumping: https://www.schneier.com/blog/archives/2019/11/tpm-fail_attack.html https://www.schneier.com/blog/archives/2019/11/tpm-fail_atta... TPM dies if your motherboard dies, so you'd need a backup key anyway. There's also no way for you to independently audit the TPM device, so you don't know how secure it really is. Personally, I don't trust Intel to keep the TPM secure, as they've shown they can't (see the above link). The keys are in the chip if you use them for FDE, so you're expanding your trust that someone with access to the TPM can never dump the keys. This could be a problem if your machine is stolen. By going the yubikey route, you can move the trust to a device that's physically on your person. That way, if the machine is stolen, there's absolutely no way to recover the keys, and there never will be even if more intel vulnerabilities are found. You could use a yubikey for the FDE keys, and only use TPM for trusting the boot device. But if you're already carrying a yubikey to decrypt your device, you might as well boot off USB too.
AdmiralAsshat 7y ago
I peaked at some of the stats regarding his brute force attempt, but I couldn't figure out how much progress he was making and whether a bf was actually feasible with LUKS. Is it something to be concerned about at this stage?
- loeg 7y ago
  LUKS1 (2004 design) uses PBKDF2 with 2 seconds worth of iterations. It's not especially susceptible to brute force. The only reasons to be concerned are (1) your password is very weak, or (2) you initialized the LUKS volume on an extremely low power or heavily oversubscribed CPU such that 2 seconds of PBKDF2 iterations is below the 2016 NIST recommendation for 10,000 iterations. (The LUKS implementation may/should have an iteration floor that would make this (2) concern invalid, but I'm unfamiliar with the codebase and unable to speak to that.) LUKS2 uses argon2. See, e.g., Cryptographic Right Answers[1]: > Password handling > Percival, 2009: scrypt or PBKDF2. > Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2. > Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. [1]: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

105 points by dvaun 7y ago

loeg 7y ago

Maybe it goes without saying, but for this to work, your password must be bad to begin with. Or at least, the article does not point to any significant design weaknesses in LUKS; it instead documents a variety of ways to get passphrase-encrypted secrets into existing tools for bruteforcing passwords. The article suggests it is about backup or data recovery, but I think it is probably more interesting to people in the business of digital forensics.

polack 7y ago
I agree with you, but I actually used the brute force for data recovery. I had a NAS with a 22 characters passphrase that I had up and running for years and eventually forgot the password to. When I set it up I practiced the password enough times that I was sure I would never forget it so I never stored it anywhere. After years of never rebooting the NAS parts of the passphrase eventually got blurry and when I was about to move I realized I couldn't remember it anymore. I didn't really have anything of high value stored on it, but it kind of became a pet project to try to "crack" into it again. Together with Hashcat and the extracted header I eventually managed to brute force it after a couple of weeks :)
- CaptainMarvel 7y ago
  How did you brute force 22 characters? Did you somehow use your fuzzy memory of the password to help?
  - polack 7y ago
    Yes, sorry I was unclear about that. I knew multiple parts of it, but not what position the segments would go into. I had also mixed the passphrase up with another old obsolete one, so I had too many of these segments (back then I broke up the passphrases into blocks of 4 chars in my head) to fit in. There was also a couple of chars that I was uncertain about so those got "fully" brute forced. The worst part about the process was that it was hard to create rules for Hashcat to generate all different possibilities for the passphrase with all the information I knew about it baked in.
    - MawKKe 7y ago
      So.. nothing to do with LUKS?
      - lucb1e 7y ago
        Just because luks isn't bad doesn't mean you can't use cracking tools to recover data when you forgot half the password, only have surveillance footage of the password being typed, have a bad password, etc. Since the article doesn't document any (new) luks weaknesses, none of the comments will be about luks being insecure.
    - MayeulC 7y ago
      I've been in the same situation multiple times. I don't recall a case where the data was of critical importance, so I could get away with it, but using the parts of the passphrase I knew in a combined bruteforce/dictionary attack definitely crossed my mind. Do you have some links to reference material on how to achieve that?
- DyslexicAtheist 7y ago
  one way to solve the problem of memorizing (long passwords) is to use something like this: to avoid forgetting it use a string of words that make sense to your brain[1] but are unlikely to be encountered in the wild (in any texts). Example passphrase: "My hamster kicks soapy homework with smurf locks like a tandem at 45 o clock!" Then use this to generate a hash which can never be remembered in itself, and is unlikely to be brute-forced: $ echo -n "My hamster kicks soapy homework with smurf locks like a tandem at 45 o clock!" | sha512sum 7364796a1ad957d7c524165aa2fec2501eaa59e6bd8380bad3252504cdb8592018e30ae2fff1b2c2295e6da7a7f47f52ef1c0e3010c054598d76fe0c6d64bac6 - this way there is no need to remember the hash itself as long as you know how to recreate the hash (+ have the tooling present like sha512sum). In case you want to change the hash without having to remember a new passphrase just twiddle with the input string (by changing one character only) to get a totally new hash. If you're on a multi-tenant machine this is probably dangerous since running `ps` might show other users on the system the input string when you run the command. Not an issue with single user systems. In case you want to avoid the command being recorded in your shell history file you can prefix the whole command with a blank (space). Benefit of this is you get a pretty long hash that is impossible to brute-force and extremely hard to remember, which makes it really useful as a master-password.
  - Thorrez 7y ago
    One weakness of this is that sha512sum is a fast hash, ideally it would use a slow and memory hard-hash. Of course if your password is strong enough it doesn't matter. An example attack would be an attacker compromises the password database of a site you use, and that site doesn't hash passwords. Next the attacker cracks that hash, which requires your password to be somewhat weak, but is aided by you not using a slow hash. Next the attacker uses that cracked master password variation to crack your LUKS setup. While LUKS uses a slow memory-hard hash, the attacker doesn't need to do many attempts, because the password is a small variation of the password the attacker already knows.
    - zaarn 7y ago
      That would matter less if you use the hash as a password as the comment suggests; in that case it matters what the website below in the stack uses.
Nokinside 7y ago
Ofthentimes password is there to discourage. Information is sensitive but it's more important that you can get it even if you lose the password than keeping it secret. And sometimes you have a really good long password that decays in your memory until you can't get it right. After few hundred tries you must either give up or start cracking it systematically using parts that you remember.
- mirimir 7y ago
  Yeah, been there. I have a few LUKS encrypted backup drives with forgotten passphrases. And in many cases, I've also forgotten what's on them. At least one has a fortune in Bitcoin, I suspect. But the passphrases are all ~50 or more characters.
badrabbit 7y ago
Could luks have been designed to use memory-hard hash funcrions to prevent brute forcing like this?
- aaronmdjones 7y ago
  LUKS2 (the current version) does support Argon2 with up to 4 GiB of memory and 4 threads.
- loeg 7y ago
  Per the article, LUKS is designed to use 2 seconds of PBKDF2 iterations, which is going to be vastly greater than the 2016 NIST recommended minimum of 10,000 iterations. So brute forcing is already quite slow, although not as memory hard as newer KDFs like scrypt/argon. It's not a bad design for 2004. As the sibling commenter and article point out, LUKS2 defaults to argon2i with 2 seconds of iteration time and 1GB of memory, 4 threads.
  - mrb 7y ago
    Actually LUKS uses 1 second of iterations, last time I checked, and according to the code: https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/libcryptsetup.h#L323 https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/lib...
    - loeg 7y ago
      Nope. That's a comment on a tangentially related function declaration; it happens to be inaccurate. Here is where the default is actually specified (2000 ms): https://gitlab.com/cryptsetup/cryptsetup/blob/master/configure.ac#L579 https://gitlab.com/cryptsetup/cryptsetup/blob/master/configu... CS_NUM_WITH([luks1-iter-time], [PBKDF2 iteration time for LUKS1 (in ms)], [2000]) See also https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/utils_pbkdf.c#L27 https://gitlab.com/cryptsetup/cryptsetup/blob/master/lib/uti... . const struct crypt_pbkdf_type default_pbkdf2 = { .type = CRYPT_KDF_PBKDF2, .hash = DEFAULT_LUKS1_HASH, .time_ms = DEFAULT_LUKS1_ITER_TIME };
mirimir 7y ago
Yes. Or people into illegal digital forensics. But for any of them, they can copy the relevant section to crack, and bruteforce massively in parallel. So I use ~50 character passphrases for LUKS. None are written or stored. All from my memory. Still, with enough fast processors working in parallel, that could probably be cracked within a few years. But then, given my age, there's a fair chance that I'd be dead before they managed it.
- bostik 7y ago
  > So I use ~50 character passphrases for LUKS. [...] with enough fast processors working in parallel, that could probably be cracked Let's do some napkin math. I'm going to make a blind assumption that you are a native English speaker, which gives us entropy estimate of ~1 bit per character.[0] Let's be generous and assume your passphrase has 51 bits of entropy, which makes the following numbers nice and round. To exhaustively search through half the passphrase space, the cracking rig will need to try 2^{50} =~ 10^{15} times. [50 * ln(2) =~ 50 * 0.301] The default master password hashing scheme in LUKS is PBKDF2, and for modern setups, argon2. The article throws around a few hashing speed ballparks, but depending on the setup we're talking about on the order of 1000 hashing attempts per second, per core. (Yes yes, the OP has figures with the argon2 numbers at about half that - I'm being very conservative here.) So, for a single LUKS passphrase crack we're talking, on average, of about 10^{12} core-seconds. A core-year is about 3 * 10^{7} seconds. So, with a single core the brute-force would take, on average, about 10^{5} years. As such... in order to break one of your passphrases, an attacker would need to dedicate 10k core-years of CPU time. That's a lot of hardware and cooling, but it's certainly not infeasible. You would need to be pretty attractive/dangerous/high-value target for anyone to spend that kind of money, though. Then the final step, threat modeling. For a normal techie, a passphrase like yours should be safe enough. For someone with access to material such as top hedge fund secrets, or into dangerous and politically juicy activities, attacking their passphrase is well within reach of a determined and well funded organisation. 0: https://people.seas.harvard.edu/~jones/cscie129/papers/stanford_info_paper/entropy_of_english_9.htm https://people.seas.harvard.edu/~jones/cscie129/papers/stanf...
  - mirimir 7y ago

luksflux 7y ago

Good luck with people like me. As ypu know, luks per default allows over 8 megabytes of key, so, i just make a dev/urandom file that is up to the byte filling the top default keysize, which means a password of over 8 million characters, of which none or very few at best are found via the keyboard. I use at the minimum 8 million chars on all my luks devices. And I've set the key stretching to take above 15 mins to unlock, even with the right password, so good luck with John the ripper.

newnewpdro 7y ago
Where are you storing that? Is it then encrypted with a passphrase?
unixhero 7y ago
How do you modify the to e required between attempts?
- unixhero 7y ago
  *time
dharmab 7y ago
Either the key is stored unencrypted on a physical device, which can likely be seized by an attackers who has access to the ciphertext, or is encrypted with a passphrase. This isn't doing anything the master key and passphrase isn't already doing. (The key you input is not the key used to encrypt the data.)
- acqq 7y ago
  The advantage of using a long key (generated randomly) is that bruteforcing of the material protected with the key is impossible, which does matter in some scenarios: specifically, if one trusts the container format, knows that the container will be accessible to the potential attackers who can try to brute force it, but also knows that the rest (the long key used) won’t be accessible to the said attackers. Which can be a reasonable scenario. Whoever uses a password manager should use reasonably long keys generated randomly. The real problem, like always, is key management. And knowing what is “overkill” for a given scenario, i.e. where reasonability ends. 8 MB is really something that should have some additional reasons than just protection from brute forcing the key.

Aardwolf 7y ago

I admit I didn't read the entire article, I've been reading only the text around instances of argon and PBKDF, but: can someone ELI5 how they do 882 hashes per second if PBKDF2 is set up to take 2 seconds, for example? What's so broken about PBKDF2 that they get a > 1000x speedup?

simcop2387 7y ago
It's trivially parrallelizable so I suspect that they're doing it on a gpu or something like that.
- wongarsu 7y ago
  Which is a known "vulnerability" of PBKDF2. In any modern setup you are better served by Argon2 (or if that's not available at least scrypt). CPU time is cheap to parallelize, memory bandwidth is much harder to scale.
  - Aardwolf 7y ago
    There must, in addition to memory, be other things that are hard to parallelize on GPU's, right? How would 64-bit integer division do on a GPU? The GPU does not have 1000x more transistors than a CPU, it can't be 1000x faster for everything, right? The annoying thing is LUKS1 only supports PBKDF2, but LUKS2 comes with a JSON parser, and no full support everywhere yet
    - simcop2387 7y ago
      The best targets are stuff that is data dependant for behavior and memory size for current gpus. Larger number sizes will help but maybe not as much as you think, since those work well for FPGA or asic devices. Data dependency helps because it can kill cache behavior and branch prediction which are key features for fast speed on fpga and gpu devices. Combined with memory size which limits the number of possible attempts on devices thats where the protection comes from. N.B. sorry for typos, have a cat in the way
    - 7y ago

quotemstr 7y ago

Sure. That's why I wish I could do LUKS authentication via TPM, which can do hardware rate-limiting. Is this kind of setup possible these days?

anon9001 7y ago
You can use a yubikey to do it. It can work in challenge/response mode, so the yubikey is required to unlock the device. That's good for laptops. You can also use a private gpg key and an gpg-encrypted keyfile. Yubikey can store gpg keys (with attestation if you want), and you can enable both yubikey access and gpg in initramfs. That's good for servers if you pair it with initramfs sshd. TPM is kind of broken, as I understand it, so I didn't even bother looking into it. There's really no reason I can't carry my keys on my physical keychain, so I don't see a need for TPM. I can also put a USB stick on my keychain and use that to boot. That way even if an attacker has physical access to the hardware, it would be require some really advanced firmware/microcode hackery to compromise the machine.
- quotemstr 7y ago
  How is TPM broken? I'm curious.
  - anon9001 7y ago
    Some TPM chips are vulnerable to key dumping: https://www.schneier.com/blog/archives/2019/11/tpm-fail_attack.html https://www.schneier.com/blog/archives/2019/11/tpm-fail_atta... TPM dies if your motherboard dies, so you'd need a backup key anyway. There's also no way for you to independently audit the TPM device, so you don't know how secure it really is. Personally, I don't trust Intel to keep the TPM secure, as they've shown they can't (see the above link). The keys are in the chip if you use them for FDE, so you're expanding your trust that someone with access to the TPM can never dump the keys. This could be a problem if your machine is stolen. By going the yubikey route, you can move the trust to a device that's physically on your person. That way, if the machine is stolen, there's absolutely no way to recover the keys, and there never will be even if more intel vulnerabilities are found. You could use a yubikey for the FDE keys, and only use TPM for trusting the boot device. But if you're already carrying a yubikey to decrypt your device, you might as well boot off USB too.

AdmiralAsshat 7y ago

I peaked at some of the stats regarding his brute force attempt, but I couldn't figure out how much progress he was making and whether a bf was actually feasible with LUKS. Is it something to be concerned about at this stage?

loeg 7y ago
LUKS1 (2004 design) uses PBKDF2 with 2 seconds worth of iterations. It's not especially susceptible to brute force. The only reasons to be concerned are (1) your password is very weak, or (2) you initialized the LUKS volume on an extremely low power or heavily oversubscribed CPU such that 2 seconds of PBKDF2 iterations is below the 2016 NIST recommendation for 10,000 iterations. (The LUKS implementation may/should have an iteration floor that would make this (2) concern invalid, but I'm unfamiliar with the codebase and unable to speak to that.) LUKS2 uses argon2. See, e.g., Cryptographic Right Answers[1]: > Password handling > Percival, 2009: scrypt or PBKDF2. > Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if nothing else is available PBKDF2. > Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then if nothing else is available PBKDF2. [1]: https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a...