Cc: Jeff Garzik <jeff@...>, <netdev@...>, <linux-kernel@...>, Andrew Morton <akpm@...>, Brandeburg, Jesse <jesse.brandeburg@...>, Chris Peterson <cpeterso@...>, <tpmdd-devel@...>, <tpm@...>, Herbert Xu <herbert@...>
Just think a little bit: system has no randomness source except the
hardware RNG. you do your strange randomness verification. if it fails
what do you do? You don't feed anything into your entropy pool and all
your random output is predictable (just boot time) If you add anything
predictable from another source it's still predictable, no difference.
Also in general what happens in the hypothetical
case that your random generator e.g. generates all zeros (which
is very unlikely but let's assume it): your entropy doesn't get
significantly worse than it was before. Previously it was just
seeded with the boot time (or other sources) and now you're adding some
zeroes. The output is still as random as the previous state.
While that changes the state of the entropy pool it doesn't make it any
easier to predict.
The only problem you got from possible bogus input is that the entropy
counts will be wrong, but in my experience nearly all programs
use /dev/urandom anyways because /dev/random is just a DoS waiting
to happen and user space programmers know that.
Basically with this insisting on FIPS you're violating the
strong variant of Steinbach's rule: not only "never test for an
error condition you don't know how to handle", but
"never test for an error condition you can't handle"
Also why do you not trust your random generator but trust
your CPU to correctly execute the cryptographic algorithm?
Not trusting your own hardware doesn't really make any sense here.
Yes and which makes them about useless because distros don't run that
daemon by default so users don't get the feature. Besides it's all not
needed anyways because the FIPS verification is pointless.
-Andi
--
