Via puts RNGs on new processors

[Peter Gutmann]

t.c.jones at att.net top-quotes:
>>t.c.jones at att.net writes:
>>
>>>FIPS certification requires a certain miminal tests of RNG functionality
>>>every time the process is started.
>>
>>Presumably we'd see this as a standard part of the POST (power-on self-test)
>>option in Nehemiah-aware BIOSes, just as various other CPU-specific features
>>are managed by specific BIOSes.  There'd also be a "Continue anyway if TRNG
>>test fails" option, enabled by default so as not to inconvenience users.
>
>The POST is really the wrong place to put it.  Nothing reads the POST data -
>it is not std across anything.  And the O/S is the code that is validated for
>NIST.  So the o/s would need to re-run the validation in any case.   ..tom

My main point wasn't where it's done, it was that users don't care whether it
passes some test or not, they just want to use it, so whether a failure is
ignored in the POST or later on doesn't really matter.  From the vendors'
point of view, would you want to present your users with a message "You can't
log on to your corporate network/read mail/pay a bill/$DO_YOUR_JOB because
murfle burble tech-jargon mumble mutter"?  Of course not, you record a
suitably vague warning in the syslog somewhere and continue anyway, falling
back to a software-only RNG, or possibly just rand().

A more succint way of putting that is: If you have something whose failure
will prevent users from using their machine, you'd better either make sure it
never fails or you have a very good returns policy.  If it's something whose
failure appears to the users as an otherwise functional unit that refuses to
cooperate, you'd better make damn sure it never fails.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com