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.