I suppose that means if someone managed to get their hands on a database with MD5 hashed password and we disregard the time it takes to query the harddrive for a match; it could (stupidly) brute-force it's way to any 5 character password consisting of a-Z, 0-9 and !"#€%&/()=?+ in about 0.06 seconds. Or a 6 character password just under a minute.
Then again, anyone who works on md5 password "cracking" for a living would likely already have the set of all 5 character printed passwords hashed and sitting in a database ready for recall with no need to speedily crank through them.
> How much different from MD5 can that be?
Answer: Very.
(MD5: 128 bit | SHA256: 256 bit) ::
(2^256/2^128 = 2^128) => 3.40282367*10^38 of a larger keyspace.
I know nothing about the specifical implementation details of either hashing method (and I eagerly await tptacek to offer a far more comprehensive response) but I'm sure the difference in keyspace alone is enough to make this practically impossible.
Hm, there is a market value for bitcoins? 25$/hour sounds like a very good deal - as long as power consumption is less, it is a license to print money?
Maybe this is the final incentive for me to look into EC2...
I'm not a bitcoins expert - but wouldn't any jump in the availability of bitcoins necessarily cause deflation, as with any currency?
If someone finds a way to generate,say, 5x more bitcoins that what the average expected amount is - they have a temporary advantage, but once those coins hit the market, the market is diluted and will quickly catch up.
Bitcoins has replaced mining gold with generating bitcoins - so it will be harnessing server infrastructure and good code / math -vs- digging big holes in the ground.
That's true. Also, as more computing power is added to its network, the difficulty of the hashing problem is increased to maintain the bitcoin creation rate at about 50 per ten minutes.
the difficulty of the calculations is adjusted so that 50 bitcoins will be released every 10 minutes. so this would only affect the distribution of bitcoins, not generation speed.
BitCoins dynamically adjusts the computation needed in order to claim coins. It will just make the computation harder. Of course, you would get more than the other users with less CPU power.
Interesting. Would you mind sharing some information regarding your hardware and performance (ghash/s)? Does your estimate include amortization of hardware cost, electricity consumption? Because the general consensus is that BTC generation is not cost-effective unless:
a) One does not pay for resources consumed.
b) Speculates about future value of BTC.
Regardless, very impressive. I would love to hear more!
What is the minimum safest length when using MD5? I remember seeing 14 somewhere but I cant find the citation. Not forcing everyone to use 14 chars of course but adding salt.
This only gets faster, not slower. No matter how much you salt your passwords, soon they will be able to crack your passwords fast enough. And soon there will be rainbow tables of salts.
bcrypt or scrypt (http://www.tarsnap.com/scrypt.html).
bcrypt lets you more or less arbitrarily set the computational complexity (in terms of instructions) of key generation. scrypt is newer (2009), but has the attractive property that it lets you arbitrarily set the memory complexity instead (how much memory it takes). This is attractive because key generation with a large memory requirement is more expensive to massively parallelize with an ASIC/FPGA farm.
If you have a seriously good reason for not using either of these, which you probably don't, "stretched" (iterated thousands of times) and salted SHA-2 or MD5, or PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ) can be acceptable alternatives.
the point of adding a salt to the passwords is not to make decrypting the individual passwords harder - the salts are kept in plaintext - but to make it impossible to prevent the use of rainbow tables. that is, having longer salts will only make it harder for finding out all the people with the same password.
My prediction: After there are loads of MD5 rainbow tables with all the passwords a human could use, people will make rainbow tables with salts. First one byte of salt, then two. Granted this gets exponentially harder, but eventually it'll be close.
(Windows' newest password hashing algorithm, NTLM, is just a plain MD4 hash of the password. I estimate my 4x5970 machine can crack NTLM hashes at a rate of about 45 billion per second.)
Here are the usage instructions...sure sounds like brute force to me. Perhaps you could explain why it isn't?
Usage: ./whitepixel [OPTION]... [<hash>]
Main arguments:
-c <charset> Generate candidate passwords using the specified charset
which can be:
lower Lowercase
upper Uppercase
digit Digits
print Printable ASCII characters and space [0x20-0x7e]
all All bytes [0x00-0xff]
(default: lower)
-l <length> Attack passwords of this length (default 5)
<hash> MD5 hash to attack (default 00...00)
36 comments
[ 3.4 ms ] story [ 83.3 ms ] threadThat's pretty impressive.
http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Think of all the BitCoins they could create with a setup like that (I get an average of 50 coins every 26 minutes with http://www.alloscomp.com/bitcoin/calculator.php).
At a current market value of about USD$0.22 per coin, this equates to about USD$25/hour.
Of course, BitCoin uses SHA256, but how much different from MD5 can that be?
(MD5: 128 bit | SHA256: 256 bit) :: (2^256/2^128 = 2^128) => 3.40282367*10^38 of a larger keyspace.
I know nothing about the specifical implementation details of either hashing method (and I eagerly await tptacek to offer a far more comprehensive response) but I'm sure the difference in keyspace alone is enough to make this practically impossible.
Maybe this is the final incentive for me to look into EC2...
http://blog.zorinaq.com/?e=42
(This is the machine I built to develop whitepixel).
If someone finds a way to generate,say, 5x more bitcoins that what the average expected amount is - they have a temporary advantage, but once those coins hit the market, the market is diluted and will quickly catch up.
Bitcoins has replaced mining gold with generating bitcoins - so it will be harnessing server infrastructure and good code / math -vs- digging big holes in the ground.
a) One does not pay for resources consumed. b) Speculates about future value of BTC.
Regardless, very impressive. I would love to hear more!
This only gets faster, not slower. No matter how much you salt your passwords, soon they will be able to crack your passwords fast enough. And soon there will be rainbow tables of salts.
cf. http://codahale.com/how-to-safely-store-a-password/
If you have a seriously good reason for not using either of these, which you probably don't, "stretched" (iterated thousands of times) and salted SHA-2 or MD5, or PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ) can be acceptable alternatives.
(Windows' newest password hashing algorithm, NTLM, is just a plain MD4 hash of the password. I estimate my 4x5970 machine can crack NTLM hashes at a rate of about 45 billion per second.)
Technically, NTLM will always be the "newest" unless they invent something newer, but it doesn't mean you need to use it.
How am I misleading?