Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b578c6b69e388257bb8f80828d75a7a5@smtp.hushmail.com>
Date: Mon, 25 May 2015 23:18:32 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: interleaving in SHA256 & SHA512

On 2015-05-25 10:05, magnum wrote:
> On 2015-05-25 05:39, Lei Zhang wrote:
>> [x8]
>> (core dump)
>
>> I think there's some memory bug in saph or somewhere else. I'm still
>> investigating it.

> Jim has had a habit of sometimes making assumptions instead of using
> the correct macros at hand. I guess there's some left to fix.

> In this case though, I have a feeling he/we simply don't support this
> high para (we really should support up to 5 or so, and whenever we have
> such limit we should include a #warning in the code if higher is tried).

This is even "documented" in SAP H format:

/*
  * Assumption is made that SIMD_COEF_32*SHA1_SSE_PARA is >= than
  * SHA256_COEF*PARA and SHA512_COEF*PARA, and that these other 2
  * will evenly divide the SIMD_COEF_32*SHA1_SSRE_PARA value.
  * Works with current code. BUT if SHA1_SSE_PARA was 3 and
  * SIMD_PARA_SHA256 was 2, then we would have problems.
  */

This must be rewritten. We can't assume anything of the sort. 
Unfortunately this is not the only format by far. Assumptions like this 
are the cause for the majority of my bug hunting this year :-(

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.