On Mon, Nov 10, 2008 at 05:55:08PM -0800, Kevin Bowen wrote: > > As far as I understand PBKDF2, the key without the salts is completely > > useless. As far as I can tell, both salts are generated in cryptsetup > > This would seem to be the key question... I hope you're wrong, but > suspect you're right. > > I spent the last couple hours stitching together a hybrid image from > various bits of a clean luks loopback device and my real device image, > using the phdr from the clean image, with mk-digest, mk-digest-salt, > and keyslot 0 salt from my real image patched in, and then everything > past byte 592 (key material + payload) from the real device. In other > words, just based on the hope that maybe the salt values from the real > device might somehow still be valid, despite evidence to the contrary. > > The resulting image is recognized by luksDump as a valid luks device, > with correct-seeming values for all the cipher specs and parameters... That would make sense. Until you try to decrypt a key, the header combined should be perfectly valid. > luksOpen'ing it prompts for a passphrase..... and then cryptsetup pegs > my cpu at 100%, and sits there with no output. Damn. > > I would think that luksOpen would error out on failure, rather than > just sitting there eating cycles..... weird. Indeed. > It's starting to sink in now that my data may be toast. This sucks. > > > attack on two key-strength 256 bit random numbers would be needed to > > recover the data, even if the key material is intact. That would be > > infeasible. > > Pardon my crypto-ignorance, but when you say 'infeasible', do you mean > NSA infeasible, or desktop class machine infeasible? Would, say, a > year or two of 8-core cpu time do any good? I mean NSA infeasible. Sorry. What you can do yourself is in the 32-64 bit range, depending on cipher complexity and effort to recognize a good result. The PBKDF2 key setup runs through 1000 iterations of a hash to determine the key, which puts what you can brute force closer to 32 bit. Keep in mind that each bit doubles effort and you see what 256 bit would require. Also keep in mind that the key is ''only'' 128 bit, so going for that directly would be easier. 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 - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
