Some issues with the integration of RDRAND about rng-tools HOT 4 CLOSED

so....don't use it.

The fact of the matter is, other users on a local system will always have access to the rdrand instruction, as it is unprivileged, or sufficiently so that rngd has no way to know who may be able to access it. If a user is so concerned with attackers having predictive access to this entropy source, the only practical solution is to turn that source off as an input to rngd (something we already have an option to do)

As for properly crediting the amount of entropy pulled from this source, 128 bits per 2^14 bytes is insanely slow, to the point where the source is effectively useless. Given that the average users values rngd as a source of sufficiently random data to feed the kernel random pool quickly so as to avoid blocking on /dev/random reads during critical times (like boot), we're not going to default restrict the strength of the source to the value you suggest above. I would be willing to entertain a patch from you that added an option to opt in to restricting the entropy count to that value when set, but I promise you no one will use it for any practical purpose.

from rng-tools.

Such a behavior would would be useful for any vendor that actually had to explain why the linux RNG was securely seeded to some specific security level. In the abstract, this is required for any product that needed to undergo FIPS 140-2 / CC (to various PPs) / AIS-31 validation.

Even if an attacker doesn't have local access, rngd is still over-crediting the entropy by a multiplicative factor of at least 511.

from rng-tools.

Several distributions ship rngd exactly as is, and certify with it against FIPS-140-2 / CC, I work for one of them.

If you would like to see it be stronger, as I noted before, you are welcome to write a patch that allows for an opting into that model, I'm happy to review it.

from rng-tools.

"I don't want /dev/random to block" can be accomplished by just using the RNDADDTOENTCNT ioctl to manually set the kernel's internal kernel entropy estimate (or asking rngd to use /dev/urandom as an input source, which is something that I've actually seen in various folk's "using rngd" instructions!) In order to provide some useful benefit, this tool needs to both introduce additional entropy into the input pool, and not misrepresent the amount of entropy that should be credited.

I'll follow up with a patch.

from rng-tools.