[lkml]   [2005]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more flakey than harddrives), this is not a problem.
> The reason some people use hardware RNGs in the first place is because
> they don't trust the software RNGs. When the hardware RNG fails but
> continues to send data to /dev/random, /dev/random essentially degenerates
> into a software RNG. Now granted /dev/random is a pretty good software
> RNG, however, for some purposes it just isn't good enough.

It seems to me that people wanting this level of assurance should do
their own FIPS (or whatever) tests.

Interrupts are not totally unpredictable, either, yet noone runs FIPS
tests on them. I'd say that hardware generator is still better than
interrupt timing. If someone really wants casino-level of randomness,
they should do it all in userspace, probably off interrupt entropy
sources, and do their own FIPS testing.

> Otherwise we can just do away with it and always use /dev/urandom.
> Someone else raised the example of Casinos using hardware RNGs. Some
> of them are doing this to comply with government regulation. In that
> case, using data from the software RNG when the hardware has failed
> would be violating the law.

Well, you are still using hardware RNG, but failed one. I do not see
how you can break law with that... given that hardware RNG had proper
certification in the first place.
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.159 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site