Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Mar 2011 18:21:59 -0500
From: "jfoug" <>
To: <>
Subject: RE: Speedup of x86 .S build of raw-sha1 format

This is saved_key

unsigned char saved_key[80*4*MMX_COEF];

>From: RB []
>> +           //memset(saved_key, 0, sizeof(saved_key));
>> +           memset(saved_key, 0, 64*MMX_COEF);
>For the memory-management poor but intellectually curious on the list,
>can you explain why?  Is it just because we avoid sizeof() in what I
>presume is a tight loop?  What happens if saved_key is larger than
>64*MMX_COEF, or can that even happen?

The first 64 bytes (times MMX_COEF) are used for the 'key'.  The later bytes are used as feedback bytes (i.e. temp vars).  It appears those are first written to, before they are read.  Thus, that is why I think only cleaning out the first 64 bytes (ignore the MMX coef), is adequate enough.

The way the SSE for SHA 1 works, is after the first 16 'rounds', it kicks into a different subround. This subround 'feeds' in some of the data from the prior 64 bytes, and writes this stirred value, into the end of the array.  Thus, this working set of feedback data, is always in a prior 64 byte window.  Thus, for SHA (as implemented), the input buffer is 16 int32's, but it requires 16+64 of these int32's.

At least this is what I 'believe' is happening.  The first 16 int32's are the only input that is read only.  The last 64 are write-first, then read.


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.