Re: identical input, different output?

[Solar Designer <solar@openwall.com>]

On Fri, Dec 05, 2014 at 12:24:27PM -0800, Colin Percival wrote:
> On 12/05/14 07:59, danielw@emaildoge.com wrote:
> >> Which version of the scrypt code are you using?  If you're using the SSE2
> >> version, are you sure that you're running on an SSE2-enabled CPU?
> > 
> > Do you mean to say that if you run the crypto_scrypt-sse.c function on a
> > non-SSE CPU, you will get a different result than on a SSE CPU?
> 
> My understanding is that some non-SSE CPUs treat SSE instructions as NOPs.

I am not aware of any such CPUs.  I think the problem is different.  The
behavior I first saw with scrypt's SSE2 code ~2 years ago was that on
CPUs that support SSE, but do not support SSE2, the few SSE2 instructions
that scrypt uses get misinterpreted as their MMX counterparts (thus
64-bit instead of 128-bit), resulting in incorrect computation (no
crash).  In particular, I think this applies to all Pentium 3 and P3
Celeron CPUs.  It might also apply to Athlon and other CPUs of the era.
IIRC, the problem is not seen on pre-SSE CPUs (e.g., it is not seen on
Pentium 2), where the program crashes on the plain SSE instructions.

This is just a peculiar detail of how the x86 instruction set evolved.

Unrelated to the CPU issue above:

Another suspect is C strict aliasing rules violations, which I think are
present in scrypt's current -nosse and -sse code.  I was able to trigger
misbehavior in -nosse with either unusual gcc options (aggressive
function inlining) or slight source code changes.  I was not able to
trigger misbehavior in -sse, but per my understanding the violations are
in there.  Another compiler might expose these.  (I fixed both in yescrypt.)

Of course, if it's a C strict aliasing issue, it'd be equally seen on
all CPUs, as long as the same binary code is run.  It is unclear from
Maarten's message whether the issue was seen on previously-tested binary
code or possibly on an untested new build.

Alexander