Re: identical input, different output?

On Wed, Dec 10, 2014 at 12:27 AM, Arnold Reinhold <agr@me.com> wrote:

I'd like to suggest third alerting option besides returning an error code that could be ignored or crashing the system: If a self-check fails, in addition to returning an error code, return a random value as the scrypt hash output.

You're suggesting to cater for people incorrectly using scrypt, and not checking the error code? I think there's still only two options: "something" at runtime, and "something" at compile time.

This case of changing the "something" at runtime to return random bytes, makes it harder for someone to notice. If my result was full of zeroes, I'll notice that first try. If it's full of something random, I'm not likely to distinguish that easily, until I start expecting repeatability, and even then, it would be hard to debug, maybe I'm just seeding some nonce somewhere?

The C library rand function, seeded by date and time (srand (time(NULL));) would be good enough for this, so there should be no platform dependencies.

I don't think this is the right approach - it means if someone incorrectly uses scrypt, it will encrypt files completely randomly, losing your data; and worse, it allows people to authenticate successfully just by guessing rand (i.e. guess within a few ms based on knowing the clock - something which is provided by the http headers, and many other cases)

Perhaps if the SSE self check fails, rather than random, just revert to the NO-SSE implementation (after self-testing the no-sse version) - so it still returns valid data, exactly like it should.

Sure, it doubles the program size, but on anything which might support SSE, nobody cares about a few kb of code. (For embedded, or hardware constrained, just exclude the SSE code completely - Arduinos don't have SSE) And presumably, compilers should detect SSE issues, but if the compiler is broken, we can only do it at runtime, with a performance penalty; but we should probably still consider that a compiler issue.

I think there should definitely be a way for a caller to ask scrypt to do a self-check; regardless of sse, or any other issues; but we can apply a heuristic as to whether we automatically force the self-check, or whether it's only for the caller to explicitly ask for. Possibly, the compiler has a "yes" (like detecting 64 bit), so uses SSE without a forced self-check; a "no", uses the NO-SSE; and a "maybe", like the SSE flags are on, but it's a 32-bit - in which case, compile with SSE, but force a self-check on every usage. (or compile with both, and have a runtime downgrade to no-sse)

Thoughts?

Ray