10

I'm currently using AES encryption (at home) on GNU/Linux (one of LUKS AES-256 variants with xts) and on Windows 7 (Truecrypt) with a 15 characters password (alphanumeric lowercase only plus _).

Should this be enough or would it be better to change towards a longer password. How long should it be? Recently viewing the results with GPU cracking I got a little worried. The thing is that I don't want to choose a password so long so that I'd forget it and get locked out.

Improve this question
1
  • 1
    The AES part isn't really relevant. What gets attacked is the key-derivation-function, i.e. the password hash.
    – CodesInChaos
    Commented Feb 24, 2012 at 10:46

2 Answers 2

Reset to default
15

A quick calculation:

First my assumptions:

I assume the attacker has $1,000,000 to spend over the course of two years. He's using standard graphics cards, and pays 10ct/kWh.

I assume that the KDF consists of 2*n SHA256 invocations, where n is the iteration count, and can be implemented with similar efficiency on graphics cards as plain SHA256. 1

A current graphics card gives around 6MHash/s/$ and around 4MHash/J. 2

Calculation

  • Electricity cost for 1 Hash: ($0.10/kWh) / (4MHash/J) = 7*10-15 dollars
  • Hardware cost for 1 Hash: 1 / (6MHash/s/$ * 1yr) = 5*10-15 dollars
  • Total cost for 1 Hash: 1.2 * 10-14 dollars
  • Hashes for 1 Dollar: 8*1013
  • Hashes for 1,000,000 Dollars: 8*1019

This corresponds to a 66 bit password, protected with plain SHA256. TrueCrypt uses PBKDF2 with 1000 iterations, which gives us a factor 2000 bonus, so we can subtract 11 bits, and we arrive at 55 bits.

Conclusion

An attacker willing to spend one million dollars can crack TrueCrypt passwords up to 55 bits of entropy. Estimate the value of your secrets, and adjust it appropriately.

A sophisticated attacker might use custom hardware, which would make the attack even cheaper. But I don't have any numbers at hand for how much energy custom hardware requires per hash.

A completely random password of length 15 chosen from 37 different characters has an entropy of 78 bits, and thus is safely out of range for graphics card based attacks. Note that this only applies if the password is completely random. If it has some exploitable structure, such as words or keyboard patterns, the entropy might be considerably lower.

1 PBKDF2 uses 1HMac per iterations, which in turn has 2 hash invocations

2 I base this on Bitcoin Mining hardware comparison using that one bitcoin hash consists of 2 SHA256 invocations.

Improve this answer
8
  • OK. If you put it that way it should be enough. In the future I plan on strenghtening it anyway, therefore I think for a year it's good enough.
    – user51166
    Commented Feb 24, 2012 at 17:58
  • point to note, undercase only will decrease entropy.
    – ewanm89
    Commented Feb 25, 2012 at 12:21
  • Exactly, lowercase only halves the number of characters in the set of alphabetic characters (26 less in the whole set), this it not so much for you as it is for the poster, mix in some uppercase and he has gone from 15*log2(36) to 15*log2(62).
    – ewanm89
    Commented Feb 25, 2012 at 13:15
  • @ewanm I misread your comment as "underscore", and wondered why adding a character would reduce entropy. Never heard the word "undercase".
    – CodesInChaos
    Commented Feb 25, 2012 at 13:17
  • 2
    @D.W. No idea how you got that number. I get 10 million CPU, or 4000 GPU years. But you're right that in most cases, planting a keylogger is cheaper than spending 1 million dollars to crack the password. It's also important that my calculations are based on standard graphics cards. I expect the per-crack costs for an attacker who developed custom hardware to be lower by a factor of 100 or so. I wouldn't be comfortable with 55 bits of entropy used with 1000 iteration PBKDF2.
    – CodesInChaos
    Commented Feb 25, 2012 at 15:26
4

I had a quick look at the LUKS specification - this link is not quite the latest format and you might want to check it. To partially quote from there, under section 2.3 pre-requisites:

LUKS needs to process password from entropy-weak sources like keyboard input. PKCS#5’s password based key derivation function (PBKDF2) has been defined for the purpose to enhance the security properties of entropy-weak password

Truecrypt also uses PBKDF2.

In short, LUKS uses PBKDF2 to derive your encryption key from your keyboard. This process applies a salt to make generating a generic rainbow table difficult and is also slow to compute when deriving keys, making each check relatively expensive.

A 15-character password should, therefore, be fine. PBKDF2 is designed to protect such passwords. That said - I would always advice varying character classes (use uppercase, punctuation, numerical digits too) if you can - anything that increases the entropy and length of the password is a Good Thing.

Improve this answer
2
  • I use numerical digis ("alfanumeric"). OK I think I'll increase its length and entropy as well. Thanks.
    – user51166
    Commented Feb 24, 2012 at 9:05
  • 1
    @user51166 15 characters should be plenty - better than most. If you can increase the length, you're doing well. If you can add more punctuation, different cases etc, even better. But alphanumeric + _ at 15 characters is pretty good compared to mnay passwords in use :)
    – user2213
    Commented Feb 24, 2012 at 9:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .