5 ms·

The iteration count used by TrueCrypt [in its PBKDF2 key derivation] is either 1000 or 2000, depending on the hash function and use case. In both cases, this it

by sigil 13y ago

The iteration count used by TrueCrypt [in its PBKDF2 key derivation] is either 1000 or 2000, depending on the hash function and use case. In both cases, this iteration count is too small to prevent password guessing attacks for even moderately complex passwords. Until TrueCrypt gets patched to use scrypt for key derivation, roughly how long should a volume password be to put it out of reach? Edit: There's a table in the scrypt paper from 2002 [1] that estimates the cost of various brute force attacks. Back then, a PBKDF2 iteration count of 86,000 and a password of length 40 would cost $200K to crack. TrueCrypt's choice of 1000-2000 iterations look staggeringly low in comparison. And that's not even accounting for hardware advances in the last 12 years. [1] page 14, http://www.tarsnap.com/scrypt/scrypt.pdf http://www.tarsnap.com/scrypt/scrypt.pdf

Osmium 13y ago
Somebody more knowledgeable please correct me if I'm wrong, but as I understand it: If you're using AES-128, if you have a random password with a 128 bits of entropy it shouldn't matter what key derivation function you use. That means, if your password can contain any printable ASCII character, a password length of 20 would be sufficient [1]. The huge caveat here is that the password has to be random, and most people are either incapable of remembering such a password or have no way of securely storing it. But I have no qualifications in this area, so don't take my word for it... [1] http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_...
- sp332 13y ago
  According to the chart in that article, case-sensitive alphanumerics give at most 5.17 bits of entropy per character. So that's 25 random characters. (edit: sorry, this bit is redundant because I misread your comment.) You are wrong about the key derivation though, and here's why: A key-derivation function that is very cheap and fast to calculate means it is easy for an attacker to brute-force lots of passwords to find one that matches your key. Using a slow, expensive KDF makes an attack much less feasible, by a factor of a thousand or more.
  - Osmium 13y ago
    Thanks for the explanation regarding key-derivation functions. Regarding the calculation, I was using the value for printable ASCII characters which is 6.57 bits of entropy per character.
- ReidZB 13y ago
  The use of AES is orthogonal to the issue of key derivation. In short, when we talk about key derivation, we're speaking of keys in a general sense - irrespective of purpose, they just need to be secure. With that said, if your "key" actually consists of 128 bits (16 bytes) of secure random data (with all the conditions associated with that), then you're right: the choice of KDF is mostly immaterial, so long as it preserves entropy. That's why, for example, if you're just generating a symmetric key for bulk encryption, you just grab (say) 128 bits of random data and use that as the key directly with no KDF involved. KDFs really only enter the scene when: (1) you want to generate multiple keys from one "master key" or (2) you want to generate "secure" keying material from "insecure" keying material (say, a user's password). The choice of KDF, however, mostly depends on the strength of the original keying material. For instance, if you have 256 bits of secure random information as your keying material, using something like scrypt is unnecessary; something like HKDF would be more appropriate there. (No one will ever brute-force your 256-bit value. It's just not happening: ever.) On the other hand, where the original keying material is weak, like in the case of passwords, you want to use something that prohibits rapid guessing, e.g. scrypt.
stouset 13y ago
From the same paper: > By using a key derivation function which requires 2s cryptographic operations to compute, the cost of performing a brute-force attack against passwords with t bits of entropy is raised from 2t to 2s+t operations [19]. 1,000 iterations is just shy of 2^10.
shawabawa3 13y ago
> PBKDF2 iteration count of 86,000 and a password of length 40 would cost $200K to crack Bear in mind that's a 40 character english text password which they estimated at 56bits of entropy. 40 completely random characters is ~1x10^79 (95^40 - assuming a character space of 95), i.e. 100% completely infeasible to crack forever, even if you could do a hundred trillion guesses every microsecond 100bit entropy is probably fine to avoid brute force attacks for the foreseeable future, which is around 16 completely random ascii characters (95 character space)
pencilcode 13y ago
Last i saw, django uses 1000 as the iteration count for PBKDF2. So maybe that's common nowadays and needs to be reviewed. On another point, can anyone point me to an article explaining the state of the art for user passwords storage?
- rickboyce 13y ago
  OWASP do a decent job of aggregating currently accepted practice: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
amalcon 13y ago
Disclaimer: I have not tested this extensively. This is merely an outline of the ratios involved, not a recommendation. Don't come after me if you get your password broken after reading this. The goal is to make it at least as difficult to break the master password as it is to simply brute-force the resultant symmetric key. If the key is 256 bits long, this is true even for a one-round SHA256 KDF if the password has 256 bits of entropy. Of course, that's at least a fifty-character long alphanumeric password from /dev/random. A password structured for a typical human to remember it should probably be 5-10x as long or more to meet a similar standard. Fortunately TrueCrypt does not use one-round SHA256, it seems to use 1000 rounds in a PBKDF2 construction. That doesn't mean we can use a password 1/1000th as long, because SHA256 is still very fast. Someone could use a Bitcoin ASIC to get a cost structure where hashing 1000 times is about as costly as verifying the aes256 key. Speculation: You can maybe go down to 25 random or 150-200 human-memorable characters.
- MichaelGG 13y ago
  >doesn't mean we can use a password 1/1000th as long It'd never work that way, right? You get to use a password with log2(1000) bits less. So e.g. if you use 2^24 iterations, and figure 80 bits is strong enough, then you can use a 56-bit password.
  - amalcon 13y ago
    You're right; it would only be a fixed (and not especially large) length reduction.
- jmnicolas 13y ago
  Unfortunately TrueCrypt max password length is 64 chars so in your speculation you have to use random chars.
ef47d35620c1 13y ago
I do not think this is significantly new as it has been documented in the official TC source code and various 3rd-party source code (TCHead, tcplay, etc.) for many years. I was the first to crack the majority of the TrueCrypt volumes in the 2012 Defcon - Crack Me if You Can password cracking contest using TCHead running on an old Intel Celeron processor. Write-up: http://16s.us/software/wm/Defcon/cmiyc_2012.txt http://16s.us/software/wm/Defcon/cmiyc_2012.txt Contest Page (3rd table down): http://contest-2012.korelogic.com/stats.html http://contest-2012.korelogic.com/stats.html TCHead: http://16s.us/software/TCHead/ http://16s.us/software/TCHead/
lucb1e 13y ago
> a password of length 40 would cost $200K to crack I'd love to see someone try. Here, an md5, those are super vulnerable right? This is a 9 character password. Piece of cake if I should believe the news. f1f107c27cae21b5b5b01002e9c9ead8
- explorigin 13y ago
  Well, Google search reveals nothing. I'm done.
  - lucb1e 13y ago
    Lol yeah that's how I usually check md5 hashes too. But that doesn't work: this is from /dev/urandom while filtering out only /[ -~]/. It seems people don't like that I'm proving the point by a super simple example though. And yes, my passwords are as strong as this, I don't use text passwords. Cracking 40 character passwords is absolute bullshit.
    - comex 13y ago
      Misinterpretation, not bullshit. Per another reply, the original document was about 40 characters of English text.
      - lucb1e 13y ago
        > Misinterpretation, not bullshit. Fair enough. I'm still curious about the generation method though: I can imagine that testing all texts ever published takes $200k if you go up to 40 characters, but if you use a unique text it might be different. There are a lot of variables here, including honest misspellings, punctuation use, spacing (non-tech people seem to find spaces weird in passwords), capitalization, usage of names, etc.
        tracker1 13y ago
        Maybe if we start changing the label to "Passwords" or "Pass phrase" to indicate that you can do something more expressive. It bugs me that even today, more systems (hello banks) don't support more open passwords. Even what's on a US Ascii keyboard would be nice. Two of my banks only support letters and numbers, no special characters and case insensitive.

by sigil 13y ago

Osmium 13y ago

Somebody more knowledgeable please correct me if I'm wrong, but as I understand it: If you're using AES-128, if you have a random password with a 128 bits of entropy it shouldn't matter what key derivation function you use. That means, if your password can contain any printable ASCII character, a password length of 20 would be sufficient [1]. The huge caveat here is that the password has to be random, and most people are either incapable of remembering such a password or have no way of securely storing it. But I have no qualifications in this area, so don't take my word for it... [1] http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_measure_of_password_strength http://en.wikipedia.org/wiki/Password_strength#Entropy_as_a_...

sp332 13y ago
According to the chart in that article, case-sensitive alphanumerics give at most 5.17 bits of entropy per character. So that's 25 random characters. (edit: sorry, this bit is redundant because I misread your comment.) You are wrong about the key derivation though, and here's why: A key-derivation function that is very cheap and fast to calculate means it is easy for an attacker to brute-force lots of passwords to find one that matches your key. Using a slow, expensive KDF makes an attack much less feasible, by a factor of a thousand or more.
- Osmium 13y ago
  Thanks for the explanation regarding key-derivation functions. Regarding the calculation, I was using the value for printable ASCII characters which is 6.57 bits of entropy per character.
ReidZB 13y ago
The use of AES is orthogonal to the issue of key derivation. In short, when we talk about key derivation, we're speaking of keys in a general sense - irrespective of purpose, they just need to be secure. With that said, if your "key" actually consists of 128 bits (16 bytes) of secure random data (with all the conditions associated with that), then you're right: the choice of KDF is mostly immaterial, so long as it preserves entropy. That's why, for example, if you're just generating a symmetric key for bulk encryption, you just grab (say) 128 bits of random data and use that as the key directly with no KDF involved. KDFs really only enter the scene when: (1) you want to generate multiple keys from one "master key" or (2) you want to generate "secure" keying material from "insecure" keying material (say, a user's password). The choice of KDF, however, mostly depends on the strength of the original keying material. For instance, if you have 256 bits of secure random information as your keying material, using something like scrypt is unnecessary; something like HKDF would be more appropriate there. (No one will ever brute-force your 256-bit value. It's just not happening: ever.) On the other hand, where the original keying material is weak, like in the case of passwords, you want to use something that prohibits rapid guessing, e.g. scrypt.

stouset 13y ago

From the same paper: > By using a key derivation function which requires 2s cryptographic operations to compute, the cost of performing a brute-force attack against passwords with t bits of entropy is raised from 2t to 2s+t operations [19]. 1,000 iterations is just shy of 2^10.

shawabawa3 13y ago

> PBKDF2 iteration count of 86,000 and a password of length 40 would cost $200K to crack Bear in mind that's a 40 character english text password which they estimated at 56bits of entropy. 40 completely random characters is ~1x10^79 (95^40 - assuming a character space of 95), i.e. 100% completely infeasible to crack forever, even if you could do a hundred trillion guesses every microsecond 100bit entropy is probably fine to avoid brute force attacks for the foreseeable future, which is around 16 completely random ascii characters (95 character space)

pencilcode 13y ago

Last i saw, django uses 1000 as the iteration count for PBKDF2. So maybe that's common nowadays and needs to be reviewed. On another point, can anyone point me to an article explaining the state of the art for user passwords storage?

rickboyce 13y ago
OWASP do a decent job of aggregating currently accepted practice: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

amalcon 13y ago

Disclaimer: I have not tested this extensively. This is merely an outline of the ratios involved, not a recommendation. Don't come after me if you get your password broken after reading this. The goal is to make it at least as difficult to break the master password as it is to simply brute-force the resultant symmetric key. If the key is 256 bits long, this is true even for a one-round SHA256 KDF if the password has 256 bits of entropy. Of course, that's at least a fifty-character long alphanumeric password from /dev/random. A password structured for a typical human to remember it should probably be 5-10x as long or more to meet a similar standard. Fortunately TrueCrypt does not use one-round SHA256, it seems to use 1000 rounds in a PBKDF2 construction. That doesn't mean we can use a password 1/1000th as long, because SHA256 is still very fast. Someone could use a Bitcoin ASIC to get a cost structure where hashing 1000 times is about as costly as verifying the aes256 key. Speculation: You can maybe go down to 25 random or 150-200 human-memorable characters.

MichaelGG 13y ago
>doesn't mean we can use a password 1/1000th as long It'd never work that way, right? You get to use a password with log2(1000) bits less. So e.g. if you use 2^24 iterations, and figure 80 bits is strong enough, then you can use a 56-bit password.
- amalcon 13y ago
  You're right; it would only be a fixed (and not especially large) length reduction.
jmnicolas 13y ago
Unfortunately TrueCrypt max password length is 64 chars so in your speculation you have to use random chars.

ef47d35620c1 13y ago

I do not think this is significantly new as it has been documented in the official TC source code and various 3rd-party source code (TCHead, tcplay, etc.) for many years. I was the first to crack the majority of the TrueCrypt volumes in the 2012 Defcon - Crack Me if You Can password cracking contest using TCHead running on an old Intel Celeron processor. Write-up: http://16s.us/software/wm/Defcon/cmiyc_2012.txt http://16s.us/software/wm/Defcon/cmiyc_2012.txt Contest Page (3rd table down): http://contest-2012.korelogic.com/stats.html http://contest-2012.korelogic.com/stats.html TCHead: http://16s.us/software/TCHead/ http://16s.us/software/TCHead/

lucb1e 13y ago

> a password of length 40 would cost $200K to crack I'd love to see someone try. Here, an md5, those are super vulnerable right? This is a 9 character password. Piece of cake if I should believe the news. f1f107c27cae21b5b5b01002e9c9ead8

explorigin 13y ago
Well, Google search reveals nothing. I'm done.
- lucb1e 13y ago
  Lol yeah that's how I usually check md5 hashes too. But that doesn't work: this is from /dev/urandom while filtering out only /[ -~]/. It seems people don't like that I'm proving the point by a super simple example though. And yes, my passwords are as strong as this, I don't use text passwords. Cracking 40 character passwords is absolute bullshit.
  - comex 13y ago
    Misinterpretation, not bullshit. Per another reply, the original document was about 40 characters of English text.
    - lucb1e 13y ago
      > Misinterpretation, not bullshit. Fair enough. I'm still curious about the generation method though: I can imagine that testing all texts ever published takes $200k if you go up to 40 characters, but if you use a unique text it might be different. There are a lot of variables here, including honest misspellings, punctuation use, spacing (non-tech people seem to find spaces weird in passwords), capitalization, usage of names, etc.
      - tracker1 13y ago
        Maybe if we start changing the label to "Passwords" or "Pass phrase" to indicate that you can do something more expressive. It bugs me that even today, more systems (hello banks) don't support more open passwords. Even what's on a US Ascii keyboard would be nice. Two of my banks only support letters and numbers, no special characters and case insensitive.