On Tue, 3 Sep 2013, Rickard Bellgrim wrote:
I'm still not convinced these are harmless. But I guess I'm strongly biased to only depending on a FIPS certified RNG.First Botan uses entropy sources like Intel_Rdrand, /dev/random, /dev/srandom, and /dev/urandom. Each byte gathered is counted towards the polling goal with a fixed fraction depending on the entropy type. If not enough entropy has been gathered, then
something serious is going on, and taking random from inferior sources might not be the thing to do......
it will go through the list of Unix commands, one by one sorted according to its priority. As shown by my previous example, the high priority commands created more than enough entropy. So yes, it won't get used in normal situations since you, besides the Unix commands, also have the other entropy sources that is used first.
I understand it is a list from "bad" to "EXTREMELY bad". Failure _is_ an option, especially when you're under attack.
Lets say that the filenames do get used, then yes, they will be added as entropy and counted as (bytes x 0.005) bits towards the goal of 128 bits. This will not be the only entropy, you will always have other bytes added before these bytes. Like e.g. the high resolution timestamp.
And then a million "A"s flood in from filenames in /tmp ?
What I can do is to forward your concerns to the Botan mailing list. To discuss the usage of "ls -alni /tmp" as one of the low priority sources.
Although that's the worst one, I think any command that can be strongly influenced by a local user who could also drain the entropy pool should never be used.
The key generation in SoftHSM uses a standard issue X9.31 Appendix A.2.4 PRNG with a AES-256 block cipher. The key for this block cipher comes from the HMAC_RNG, based on the design described in "On Extract-then-Expand Key Derivation Functions and an HMAC-based KDF" by Hugo Krawczyk. The HMAC_RNG is reseeded after every 1024 byte random byte. HMAC_RNG is used when the X9.31 PRNG gets its cipher key and when it refills it internal state / reseed.
I'm not a mathematician (or cryptographer) but if I understand things correctly, RNG's are still pretty vulnerable if fed with non-random entropy.
My belief is that this is good enough for a software based HSM like SoftHSM.
Noted. Paul _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
