search

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.2k stars 2.09k forks source link

LUKS format and luks2john: Support all slots, not only the "best slot" #557

Open frank-dittrich opened 10 years ago

frank-dittrich commented 10 years ago

May be this should better be discussed on john-users and/or john.dev, if so, suggest where you think the discussion is appropriate.

Just skimming the source code it looks like luks2john only considers the "best slot", and the luks format also just works on the "best slot".

Shouldn't luks2john consider all slots and either create different hashes, or just one hash (but with all appropriate slots filled), and the luks format splits the (up to 8) different slots into individual hashes?

Rationale: The picked best slot (due to lowest iteration count) might be one which uses a key file containing random data, and another slot with higher iteration count might be one with a weak password.

kholia commented 10 years ago

Sounds like a good idea :+1:

magnumripper commented 10 years ago

:+1: I wasn't even aware of those terms. Where do I find a crash course on LUKS internals?

kholia commented 10 years ago

https://code.google.com/p/cryptsetup/wiki/Specification

On Wednesday, April 9, 2014, magnum notifications@github.com wrote:

[image: :+1:] I wasn't even aware of those terms. Where do I find a crash course on LUKS internals?

— Reply to this email directly or view it on GitHubhttps://github.com/magnumripper/JohnTheRipper/issues/557#issuecomment-40000009 .

frank-dittrich commented 10 years ago

See also man 8 cryptsetup on any (recent?) linux system, especially the LUKS EXTENSION section

magnumripper commented 10 years ago

Thanks, I'm in sync now. This is a really good idea. Luks2john should not try to be clever, it should just store all keyslots for the one "hash". The format should default to attacking the slot with the lowest iteration count, but - and here I assume your work with cost comes in - it could be told to use some other one(s).

The caveat might be that without adding functionality to your implemented/planned "cost" selection stuff, it might be impossible to tell the format to attack more than one keyslot for a single "hash" at a given run, unless luks2john actually produces one "hash" per active keyslot. But the "hash" is huge so if we can avoid that, it would be nice.

magnumripper commented 10 years ago

Hm, maybe the current format interface can do this [reading one "hash" with n active slots and producing n different "hashes"] - using split()

frank-dittrich commented 10 years ago

LUKS wasn't included in any official release, so we can still change the format in any way we want.

Regarding the huge hash size: 1. In january, I suggested converting all the hex to base64 encoding: http://thread.gmane.org/gmane.comp.security.openwall.john.devel/10325

2. See chapter "2.4 AF-Splitter" of the specification. Who says we have to just dump all that stuff into the JtR specific LUKS hash? I'm sure there's a way to "compress" the information (or rather, drop stuff we don't need). Stuff not needed might be information stored in slots that are not active (instead, we store how many active slots we found, the slot numbers of the active slots, plus the information that is really needed (see AF-Splitter...)

Regarding the decision to store information of all active slots in one hash and split them in split() or produce one hash per slot: I already mentioned these 2 alternatives in my initial issue report.

Of course, john.pot will need to store almost all information of the single LUKS hash per slot that has been cracked. So when you have 4 active slots and cracked the password of 3 of them, john.pot will store the part of the hash that doesn't depend on the slot 3 times. But I doubt that you'll crack that many LUKS hashes.

The only problem I see with using split(): John might assume that the single password consists of (up to) 8 parts, and that so far just one part has been cracked. (But I might be wrong here. I didn't look at that code recently. May be the "combining several john.pot entries into a single line of john --show output" is just special for LM hashes.)

May be we should better discuss the details on john-dev. Solar might be extremely busy right now (PHC contest, OpenSSL heartbleed bug/backdoor and it's implications, ...). But if he has time, his input would be valuable. And many other people who are active on john-dev might ignore github.

Things to consider: Which of the PHDR layout and key slot layout fields to we need to store as-is, which can be dropped, replaced by an enum, or otherwise compressed? Being too aggressive in "compressing" things might also hurt if in the future we support other ciphers (but may be that would be another, separate format).

So I think there's much room for improvement in the way the LUKS format work. Unfortunately, I'm too busy to really dive into this task.

May be Dhiru would also enjoy polishing his existing format, and not just beating everybody else in the art of implementing at least 2 new formats per day ;)

frank-dittrich commented 10 years ago

While searching for formats with lacking "tunable cost" reporting, I noticed that there wasn't any progress for LUKS format. I think even if we "store" all slots as a single hash produced by luks2john, split() should produce individual hashes per slot, and the pot file should store those slot specific hashes.