What we're trying to do is hash candidate passphrases (which are cycled
through by specific human oriented rules, not nonce values apart) and
then use the result to perform an AES decrypt.
The hashing algorithm is MD5. There's a 64bit salt known to us. (was
randomly generated), and the passphrase goes through 1024 iterations of
MD5 to derive the AES initialization vector and key.
The famous collision weaknesses of MD5 are of no help to us here. Those
weaknesses help you find hash collisions -- that is, you already know
the output of the hash and want to create an input that ends up hashing
to the same (collision). We have no idea what Ian's passphrase looks
like after going through this salted 1024 rounds of MD5, all we know is
the AES ciphertext it helped create.
So this key derivation function is doing its job, we're having to go
through some busy work per guess here. 1000 rounds seems to be a common
recommendation.
But, good news, this isn't top of the line either, according to
http://en.wikipedia.org/wiki/Key_derivation_function
"NIST requires at least 128 bits of random salt and a NIST-approved
cryptographic function, such as the SHA series or AES (MD5 is not approved)"
I think this is due to MD5 being too easy for our modern machines to
whip through.
Funny enough, the link Wikipedia provides for citation on this point
goes to a nist.gov page that says:
"Due to a lapse in government funding, the National Institute of
Standards and Technology (NIST) is closed and most NIST and affiliated
web sites are unavailable until further notice. We sincerely regret the
inconvenience.
The National Vulnerability Database and the NIST Internet Time Service
web sites will continue to be available. A limited number of other web
sites may also be available."
Thank you, house of representatives. Skullspace has now been touched by
your solid lack of legislating. I better write a letter to Barack Obama
and beg him as the small child writing from dear Canada to give into
everything they want and more.
It is fortunate that the Multibit developers wanted their private key
backup export files to be compatible with the openssl "dec" and "enc"
command line suite.
https://github.com/jim618/multibit/wiki/Export-and-limited-import-of-private-keys
A popular standard for key derivation is:
http://en.wikipedia.org/wiki/PBKDF2
(I think I read this is similar to an older version of that)
Another key derivation function getting a lot more attention these days
for making GPU/FPGA/ASIC based cracking a lot harder is Scrypt:
http://www.tarsnap.com/scrypt.html
http://en.wikipedia.org/wiki/Scrypt
They claim it's 100 billion times more costlier then what the command
line "openssl enc" key derivation algorithm we're facing here entails.
And we can actually start to get a good estimate of what our attempts
per second will be. See this insane GPU based setup:
https://securityledger.com/2012/12/new-25-gpu-monster-devours-passwords-in-seconds/
180 GH/second is claimed for MD5 on a 25 GPU setup. That's potentially
7.2 GH/second for a single GPU (ours is awesome, but how awesome?) and
with 1024 MD5 iterations per attempt we're looking at 7 million
passphrase attempts per second if we ignore the cost of
iterating/generating between attempted passwords and AES attempted cost
after decrypt.
Doing the math, that's log(7000000*60*60*24, 2) = ~ 39, ~ 2 ^ 39
possibilities we can cover with just one GPU in a day, 2 ^ 47 we can
cover in a year.
See:
http://xkcd.com/936/
Another good fortune is that our cipher text is only 80 bytes and
includes PKCS 5/7 style padding that makes it easy to say "not
plaintext" on most of the results.
_______________________________________________
SkullSpace Discuss Mailing List
Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss
Archive: https://groups.google.com/group/skullspace-discuss-archive/
