A password structured for a typical human to remember it should probably be 5-10x as long or more to meet a similar standard.įortunately TrueCrypt does not use one-round SHA256, it seems to use 1000 rounds in a PBKDF2 construction. Of course, that's at least a fifty-character long alphanumeric password from /dev/random. 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. 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. Don't come after me if you get your password broken after reading this. This is merely an outline of the ratios involved, not a recommendation. scrypt.ĭisclaimer: I have not tested this extensively. 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. (No one will ever brute-force your 256-bit value. 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. The choice of KDF, however, mostly depends on the strength of the original keying material.
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). 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. 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. 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. The use of AES is orthogonal to the issue of key derivation.
Ramble over, if anyone has any figures for FPGAs or ASICs then I'd be really interested. Now the development cost of these is the expensive bit, but then your hashing rate would be insane. Granted, double SHA-256 is not equivalent to MD5, but I'd be surprised if MD5 was significantly harder, and expect it to be a lot simpler. You could buy a while ago kit that did 7GHash for $300ish, and there's supposedly some 1THash ones in development. Assuming a 5x cost/hash reduction would grab us at $8k which would be in the range of hobbyists.īeyond this, several private companies have been able to build double SHA-256 ASICs (for bitcoin mining). There are also speedy MD5 FPGA cores, I've not got a great reference but found one from 2007 which did 44MHash / core using a Cyclone II which I can only find described as "built for low cost". You can get ~ twice the hashes/$ so maybe $40k, and if you're cheap about the computers you connect with then probably lower.īut that's consumer kit. That puts us easily within the range of governments, companies and just generally rich geeks.
#TRUECRYPT CRACKED CRACK#
That means we'd need 42 cards to crack it in a week, costing somewhere in the region of $80k (1.5k/card + extras). And I only have to do this once and I forever gain the capability to break any 9 character (and below) password with just a lookup.Īnd that's assuming that MD5 is a perfectly secure hash with no shortcuts allowing you to narrow down the input set.Ī new AMD Radeon™ R9 295X2 is pretty speedy, clocking in at 23GHash for single MD5 (there are cheaper per $, but this is extremely impressive imo). In 1997.īut if I were to throw some purpose built hardware at this problem or use the video card to speed this up and not just laptops with general purpose CPU's, it's very likely I could decrease this time by thousands of times.Īt the end I's have all MD5's for all passwords, and now the problem becomes a rainbow table lookup. But if I were a government, maybe I'd get a few thousand laptops together and set about calculating this over the next five years or so. 95^9 = 630249409724609375 possibilities.ĭivide by 250 million, and we get about 2520997639 times ten minutes for the time it would take me to enumerate all possible plain text passwords. You didn't specify what counts as a character, but let's assume it's a printable ASCII character.
#TRUECRYPT CRACKED CODE#
Using non-optimized, managed code on my laptop, I just went through 250 million iterations of plain text in ten minutes.
0 kommentar(er)
