Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ