Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 May 2015 00:35:14 +0300
From: Solar Designer <>
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.


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.