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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
