Re: [dm-crypt] Recovering/Cracking passphrase

[Arno Wagner <arno@wagner.name>]

On Thu, Jun 10, 2010 at 03:28:03PM -0500, Justin Brown wrote:
> Hello,
> 
> I'm in a really bad situation. Basically, I've lost my passphrase, and I'm
> trying to find a way to recover it. I know what the passphrase should be
> (it's a really good 20 character passphrase), but I must have mistyped it
> when configuring cryptsetup or added some complexity which I failed to write
> down. I've tried about every combination of all the passwords and
> passphrases that I use, and I can't come up with anymore, so I'm going to
> try to build a cracker. I'd like to get some feedback before I put a lot of
> time into writing the code.
> 
> I'm going to build a brute-force cracker using libcryptsetup.

That only has a chance if you can heavily rely on known characteristics
of the passphrase. Otherwise you get something like 80 bit for a good
20 char passphrase, which takes, given that you have to go through PKBF2,
something like 10^15 years.

> I'd like it to go fast, so I plan to use posix threads to create four
> threads (I have a non-HT quad-core) that will:
>      1) increment the current passphrase
>      2) use crypt_activate_by_passphrase() to try to open the volume.
> I don't think that the the passphrase could be longer than 75 characters,
> which is still very long, so I understand how horribly long this will take.

I thought you said "20 Characters"? 75 is a bit different from that.
With 75 and the average 1.5 bit/char, you get something like like
1-^25 years.
 
> My original question was posted to the cryptsetup "issues" page about thread
> safeness. Would this pesudo-code be safe or do I need to fork()?
> crypt_init(&cd, "/dev/md1");
> crypt_load(cd, NULL, NULL);
> pthread_create(...);
>    generate_passphrase(); //Does #1 from above
>    crack(); //Does #2 from above
> 
> Will doing crypt_init and crypt_load before creating threads cause problems?
> struct crypt_device* cd is global.
> Would I be better off forking to avoid race conditions?
> 
> Is this approach my best chance to recover my data? 

This approach has no chance at all to recover your data. You can do 
something like 1 PKBF2/sec, so you need to bring the uncertainity 
in the passphrase down to something like 25 bit to finish within 
1 CPU year.

> Should I be trying to
> attack the master key instead?

Forget that as well, no chance.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier