[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a7965e5c08bf6134c69181e37bc3104e@smtp.hushmail.com>
Date: Fri, 7 Dec 2012 20:11:42 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: rc4-hmac parsing support + etype 17 + input format unification (Was: Re: [john-users] support for weak kerberos etypes)
On 7 Dec, 2012, at 18:30 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
> On Thu, Dec 6, 2012 at 5:38 PM, magnum <john.magnum@...hmail.com> wrote:
>> On 6 Dec, 2012, at 12:53 , Dhiru Kholia <dhiru.kholia@...il.com> wrote:
>>> On Thu, Dec 6, 2012 at 5:00 PM, magnum <john.magnum@...hmail.com> wrote:
>>>> Also, etype 17 would be super-easy to add (provided the only difference is the AES) to our current krb5ng and krb5ng-opencl formats if someone provides a sample pcap. It wont be any faster than etype 18 though. As far as I can read krbng2john.py, it would need to be modified to support this etype... would we also need to change the input format? Maybe add the etype as a separate field.
>>>
>>> I will extend krb5-ng (CPU format) to support etype 17 soon.
>
> This is done now. Hope my changes makes sense.
>
>>>> We could want to rename mskrb5 to krb5pa-md5 and krb5ng to krb5pa-sha1. Or would krb5pa-sha1-96 be better?
>>> mskrb5 to krb5pa-md5 and krb5ng to krb5pa-sha1 sounds good.
>
> New file name is "krb5pa-sha1_fmt_plug.c"
>
>>> I can make krbng2john.py output hashes in this format and add support
>>> for rc4-hmac.
>
>> Great! I will fix my formats as soon as krbng2john.py is updated. Perhaps I should do an opencl format for etype 23 too, especially if there are downgrade attacks possible. It will be a whole lot faster than etype 17/18.
>
> I am using the following format which is slightly different from the original.
>
> $ krb5pa $ etype $ salttype $ user $ realm $ timestamp $ checksum
After digging around a bit I have a slightly changed proposition... sorry! :)
Let's drop the "salt type" field. Use a "salt" field instead, and leave it blank if not available (fill in user and realm regardless). We then let the format decide what to use (for current applications we'll use salt if available, and otherwise use the concatenation of realm.user).
Also, do not split the timestamp in two fields (it simplifies the pcap parser with no downside):
$ krb5pa $ etype $ user $ realm $ salt $ timestampIncludingChecksum
The rationale is that's how it comes on the wire (timestamp and checksum in one blob). So just put that in the timestamp field - the formats will know where to split it. This will simplify addition of other etypes - I think you can actually implement them in the python script without any samples.
I can do these changes if you commit your current work (and provided noone objects to this). Or you do it if you like.
Note though that we might save ourselves some future work by researching what we'll need to include for etype 1, 3 and 16. Will this format be enough for them too?
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
