On Tue, Mar 29, 2005 at 12:38:01PM +0200, Pavel Machek wrote: > > It seems to me that people wanting this level of assurance should do > their own FIPS (or whatever) tests.
That's exactly what the current scheme of driver + rngd allows you to do. For those that require high assurance, they can let rngd do the checks. Otherwise they can disable the checks and just let rngd feed data from /dev/hw_random into /dev/random. It's not just about the quality checks. It's also about deciding the rate at which data should be fed into /dev/random. Feeding too much means that you might be wasting system resources (CPU/PCI bus/etc.). Feeding too little means that /dev/random users may block unnecessarily. Doing the feeding in a process means that you can feed exactly the right amount. You feed only when the /dev/random's pool is depleted and you feed exactly the amount of data that is needed to replenish the pool. > Interrupts are not totally unpredictable, either, yet noone runs FIPS I haven't looked at this but if that's the case we might want to look at lowering the entropy count for that. > > 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. Actually in the scheme proposed in this thread the hardware RNG could be feeding a stream of zeros into /dev/random which means that the /dev/random user will be using a software RNG. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
