[13020] in cryptography@c2.net mail archive
Re: Via puts RNGs on new processors
daemon@ATHENA.MIT.EDU (Peter Gutmann)
Fri Apr 11 11:21:31 2003
X-Original-To: cryptography@wasabisystems.com
X-Original-To: cryptography@wasabisystems.com
Date: Fri, 11 Apr 2003 17:28:20 +1200
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: pgut001@cs.auckland.ac.nz, t.c.jones@att.net
Cc: cryptography@wasabisystems.com, don@mit.edu
t.c.jones@att.net top-quotes:
>>t.c.jones@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@wasabisystems.com
