[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Dec 2012 13:08:43 +0100
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: support for weak kerberos etypes
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.
>
> Yes, Input format needs to be extended.
>
> Do you plan to use a new file for implementing etype 17 using OpenCL?
Provided the only difference is AES-128 instead of AES-256 it can be the same file. It does not affect speed so there are no problems mixing them in one run.
> I will extend krb5-ng (CPU format) to support etype 17 soon.
> 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.
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.
