[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20141218141748.GA550@openwall.com>
Date: Thu, 18 Dec 2014 17:17:48 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: scrypt
Jim,
I went to fix the known (to me) bug in the revision of
crypto_scrypt-nosse.c that got into bleeding-jumbo. (I've long since
fixed that bug in (y)escrypt, and it is not in yescrypt as actually
submitted to PHC.) And I found that you had fixed it in here already -
thanks! I am referring to commit
9ac48a24ebe5ecae14bfb248ff2cb057406627f5 and this fix:
- XY_size = (size_t)256 * r;
+ XY_size = (size_t)256 * r + 64;
However, I notice that you've included the same change in -sse as well,
in the same commit. I think it was not needed. I think the bug was in
-nosse only, because in -sse there's no "Z" in smix(). Did you make the
change to -sse just in case, knowing that it's harmless even if not
needed, or am I missing something?
I am also puzzled by:
-#ifdef __SSE2__
+#if defined (__SSE2__) || defined (_MSC_VER)
(part of the same commit). Doesn't MSVC define __SSE2__ when
appropriate? And is it appropriate for us to assume SSE2 whenever we
build with MSVC? No one would ever want a new Windows build running on
anything older than a Pentium 4? Perhaps this is so, but then wouldn't
it be more appropriate to enable the proper compiler flags?
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.
