john-users - Re: support for weak kerberos etypes

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers

[<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