Re: identical input, different output?

[Solar Designer <solar@openwall.com>]

On Fri, Dec 05, 2014 at 01:41:44PM -0800, Colin Percival wrote:
> On 12/05/14 13:41, Arnold Reinhold wrote:
> > If so a quick trial SSE calculation would reveal the absence, allowing an error return. Seems prudent. 
> 
> Yes, I'm planning on adding code to do that.  But I don't know if that's the
> issue which Maarten ran into.

Right.

I think you need to choose between these 3 approaches:

1. Invoke any SSE2 instruction (via a compiler intrinsic or inline asm?)
that has no MMX counterpart, to ensure that the code crashes on pre-SSE2
CPUs.  Need to ensure this won't be optimized out, either by using the
result of this intrinsic in a way too complicated for the compiler to
figure out and eliminate or by using "volatile asm" (less portable, but
more reliable where it is supported).

2. Perform some computation with SSE2 instructions that scrypt uses and
check the result.  Again, there's some risk of a smart compiler doing
this at compile time (assuming proper SSE2 behavior of the intrinsics)
and optimizing the check out, and again "volatile asm" would address
this (with similar pros and cons).  So it's about the same as approach
#1 above, just more complicated.  Oh, also if the program is not made to
crash on failing this self-test, this may actually be worse than #1 in
case the caller doesn't check the return value.

3. Run a self-test of the entire scrypt, with some minimal parameters
(for the overhead to be negligible performance-wise).  I think this is
actually best (and should be in -nosse as well).  If done after main
computation, this will also wipe some of the memory and registers from
sensitive data.  Hopefully, the computation will be non-trivial enough
that the compiler won't attempt to do it at compile time.  The usual
pros and cons of returning error vs. crashing apply - I am unsure which
is best in this case.  scrypt may fail (and return error) on failed
memory allocation anyway.  (Crashing on an SSE2-only instruction in code
compiled for SSE2 or better feels fair.  Crashing on a failed self test,
slightly less so, although there is clear similarity here.)

Alexander