Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Aug 2015 10:23:19 +0200
From: magnum <>
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, wrote:
>> On Mon, 17 Aug 2015 22:51:26 -0500, Lei Zhang <> 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.


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.