On 12/07/2010 22:13, Eric Murray wrote:/
On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote:
On Mon, 12 Jul 2010, Eric Murray wrote:
Then there's FIPS- current 140 doesn't have a provision for HW RNG.
They certify software RNG only, presumeably because proving a HW RNG to be
random enough is very difficult. So what's probably the primary market
(companies who want to meet FIPS) isn't available.
So you can do HWRNG - SWRNG - Fips ?
Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only.
X9.62 or FIPS 186 or X9.31 or SP 800-90.
I couldn't even use a HW RNG for the seed. /dev/random was acceptable.
The Smart Card industry uses True RNG a lot. There, a common line of
thought is to use:
- a hardware RNG, which raw output (perhaps biased) is directly
accessible for testing purposes (only), so that the software can check
it in depth at startup and from time to time to ascertain that it is at
least generating a fair amount of entropy
- followed by appropriate post-processing in hardware (so as to gather
entropy at all time), acting as a mixer/debiaser:; e.g. something LFSR-based
- followed by a crude software test (e.g. no bit stuck)
- optionally followed by software postprocessing (the subject is
debated; this software has to be proven to not include weakness, and the
hardware + crude software test is certified to eliminate such weakness,
so why bother, some say)
There is a standard, known as AIS31, on evaluating True RNG, which
de-facto enforces the first three steps
For German-reading audience, the page linking to that is
Google does good work when fed with AIS31.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com