Intel to also add RNG

[coderman]

On Tue, Jul 13, 2010 at 5:48 PM,  <dahonig at cox.net> wrote:
>...
> Obviously there are costs associated with a HW RNG as someone enumerated.
 Since Intel
> can no doubt shut it off when not used, it is free.

uh, what? you realize you're comparing a very noisy but very very
small entity against the remaining core of a modern many hundred
million gate processor right?

you can certainly disable / idle the sources when not needed, but
really, left wide open all the time they're a drop in the bucket.


> ...  So crypto hw will continue to be increasingly useful.

it is the throughput and efficiency that makes it most useful. like
the AES XCRYPT instruction in VIA Padlock cores. you may avoid a
number of cache timing and other timing based side channel attacks on
software cipher implementations using hw as well, since they often
execute one or more rounds in a handful of cycles. there are probably
other advantages.


> Since the crypto cluefull would never use a single raw RNG of any kind,

the crypto cluefull know the value of mixing a high throughput, easily
managed entropy source with host and application true random number
facilities (/dev/random, /dev/urandom, OpenSSL random engine support,
XSTORE instruction in userspace, etc.)

the key to using a hw source properly:
1. initialize, measure, and mix the raw source(s) with a userspace
entropy daemon.
2. continuously sanity check the read data over a large byte span and
remove a hardware entropy source that is not functioning within
comfortable tolerance. FIPS does have a nice suite of checks - again,
this can't prove your source is robust, only that it doesn't suck
horribly and obviously. :)
3. run the hw random data through a block cipher or hash digest to
mask generator bias before adding to host entropy facilities with a
conservative entropy density estimate. while the VIA and other good HW
sources can produce very high density output i prefer at most an 80%
estimation on input for robust distribution into the host pool as
needed.
4. periodically save state for use with mixing initialization in step
#1 on next restart.
5. monitor without writing if anomalies in the hw sources arise during
operation. with VIA XSTORE on C5P or greater (not C5XL with single
source) you have two independent sources which can be enabled or
disabled as needed. on such systems you can fall back to half-rate
throughput on the good source if the other goes bad.

if you mean "raw" as in omitting all of the steps above and just
reading /dev/hwrandom then i agree. otherwise, see above. :)


> and would even seek to use multiple diverse conditioning algorithms, cpu
> bandwidth allowing, a "hw" source can only help.

i can get > 80Mbps of entropy on VIA hw entropy sources. have you ever
tried to use /dev/random on a headless server? a recently booted
workstation? for more than a few keys at a time? etc?


> Except as someone wrote, if its the devil's hwrng, or can be clandestinely
> switched into that mode as useful.

keep secure state, properly mixed, and even a highly biased input
would be whitened and obscured beyond utility. i'd like to see
reasoning otherwise for XSTORE sources and XCRYPT AES mixing before
conservatively mixed into properly seeded /dev/random kernel pool. if
it is too biased (OpenSSL weak keys :) then the FIPS sanity checks
will kick it out and you're denied entropy rather than compromised
silently.

it's really a shame crypto isn't standard on every DIE. although if
they do a poor job of it the annoyance outweighs the utility. the SHA
instruction on Padlock borders on unusable without hacks like
interrupting the REP mode instruction with a fault/intr. so you can
grab the un-finalized work-in-progress digest state for large
lengths...

best regards,