|
Message-ID: <36739d549df4ecfaa3b084a7fe194840@smtp.hushmail.com> 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.