[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150525213514.GA31177@openwall.com>
Date: Tue, 26 May 2015 00:35:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: interleaving in SHA256 & SHA512
On Mon, May 25, 2015 at 11:18:32PM +0200, magnum wrote:
> 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 :-(
Whenever we identify such assumptions, can we please be introducing
either #if's with #error's or assert()'s (perhaps into init() methods),
until we possibly remove the assumptions later? I think a failed build
or an explicit assertion failure will be better than a failed self-test
(without immediately clear cause), or especially than a segfault, in
these cases. Hopefully, we'll notice before making a release and won't
release with settings that would trigger the #errors and asserts.
Alexander
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.
