[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8a594ca6982702ea99623bf5af5b26e8@smtp.hushmail.com>
Date: Tue, 18 Aug 2015 10:23:19 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Formats using non-SIMD SHA2 implementations
On 2015-08-18 09:05, Lei Zhang wrote:
> On Aug 18, 2015, at 12:41 PM, jfoug@....net wrote:
>>
>> On Mon, 17 Aug 2015 22:51:26 -0500, Lei Zhang <zhanglei.april@...il.com> wrote:
>>
>>> Or perhaps I didn't understand your point correctly ?
>>
>> It sounds like you understand it well enough. Now, can I ask, what variables
>> make up the growth of the lanes ? Is is solely based upon password length?
>> Keep in mind, that if it is a combination of password and salt, then all
>> you have to care about is password. Within any run, you ONLY deal with
>> one salt at a time.
>
> It's a combination of password and salt. The entire length of data to be hashed is (len(password) + 8)*rounds, where 'rounds' is solely based on salt.
That's assuming 'password' is already in UTF-16, right? So for ASCII the
number of raw SHA256 calls should be (len(password) * 2 + 8) * rounds /
64. Plus one for the final. So for length 0 it's 65537 calls to SHA256,
for length 1 it's 81921, and so on.
>> But if this variable length is solely based upon
>> length of password, then simply have 'enough' passwords, and sort them,
>> so that you work with only passwords of a given length at the same time.
>
> How do I do this exactly? If it's lengthy to explain I can chew some sample code myself :)
I believe cryptsha256_fmt_plug.c lines 619-626 is the heart of it. In
that format, groups of lengths use the same buffer size. I think for 7z
and rar3, you won't need the 'lens' static array, all lengths will use a
different number of limbs.
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.
