[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: identical input, different output?
> On Dec 5, 2014, at 7:35 PM, Solar Designer <email@example.com> wrote:
> When using intrinsics, CPUID is a safer bet against compiler
> optimizations, but we'd have to use #ifdef's to choose the intrinsic
> that the current compiler supports (and what if know no CPUID intrinsic
> for the current compiler?) If we resort to inline asm, we can as well
> put a suitable SSE2 instruction in there (to trigger crash on pre-SSE2),
> which is simpler (just one instruction), safer (no dependency on the
> caller's return value check), and more consistent (the code might have
> SSE2 instructions before that point, depending on compiler and other
> parts of the program, so a belated CPUID check feels a bit silly).
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. This would fail safe by preventing validation of credentials by the faulty code, a lapse that would be quickly detected in practice. 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.