Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
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.