Via puts RNGs on new processors

[Ian Grigg]

Don Davis wrote:
> 
> At 12:20 PM -0400 4/8/03, Perry E. Metzger wrote:
> > FYI, it appears that Cryptography Research has
> > done an evaluation on the RNG. See:
> > http://www.cryptography.com/resources/whitepapers/index.html
> 
> a one-time evaluation of the RNG's design and of
> its output aren't really enough.  there are three
> related issues, which arise because effective and
> thorough TRNG testing are too expensive:
> 
>   * production-line QA:  with modern chip-fab
>     technology, salable chip yields aren't 100%.
>     each chip gets run through a validation test,
>     to make sure that its various functions work
>     correctly, and a lot of chips get scrapped
>     because of validation failures.  unfortunately,
>     thorough validation of each chip's TRNG would
>     take too long (generate some bulk of random
>     bits, do a few hours or days of CPU-intensive
>     statistical computations...).

This could be solved by selling the chip
"as is".  With no guaruntee of performance,
leaving each user to make their own tests.

>   * surely, vendors are going to be unwilling to
>     discard a chip whose CPU and on-board memory
>     work, but whose TRNG doesn't work.  the ven-
>     dor might bother to disable the TRNG circuits,
>     and then sell the faulty chips at a reduced
>     price for non-crypto applications.  but i
>     expect that most vendors won't bother, but
>     will silently sell the TRNGs as-is.

This is apparently a solved problem; there
is a ready market for faulty chips.  For
example, memory chips with half the memory
missing are shipped off to 3rd world countries
where they are sorted according to flaw, and
constructed into memory boards with matched
flaws, so as to deliver perfectly good strip
level memory from partial components.

To combine with the first point, run the TRNG
for a couple of seconds, compress the result,
and use the result to decide whether the chip
goes into the "good" bucket or the "no-TRNG"
bucket.

>   * detection of run-time TRNG failures:  how
>     will the CPU or operating system detect that
>     the TRNG has stopped working properly?  surely,
>     neither the CPU nor the OS is going to spon-
>     taneously sample and test the TRNG's output
>     for randomness failures, because proper RNG
>     testing is computationally expensive.

No guaruntee, then no problem.  This seems
to be a userland problem, solved by some
user program that tests the output, run on
an application basis.

The main thing about use of random number
sources is to never trust a single source;
for this, a framework is needed to combine
several sources and measure entropy into
the result.  Kelsey et al wrote a paper
that described such a framework, called
Yarrow, and this appears to be the one
most used in the practical software world
(goodle on Kelsey and Yarrow).

>From that point of view, an on-chip RNG
would be a really useful input into Yarrow.

-- 
iang

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