Am Freitag, 17. April 2015, 21:11:37 schrieb Herbert Xu: Hi Herbert, > On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote: > > Do you really think that this is possible? If the DRBG becomes the stdrng, > > you would imply that those callers (e.g. IPSEC) may suffer from a long > > block (and with long I mean not just seconds, but minutes). > > It's only 49 bytes for every 64K so I think it's reasonable. Just an FYI on a test I did once: on a headless PPC (POWER6), we drained /dev/random (simply do a cat /dev/random). Then it took more than 20 hours(!) to get 48 bytes to seed OpenSSL from /dev/random. This test was done on some 2.6.32 kernel. That issue should be better now considering that interrupts are used as noise source by /dev/random. Furthermore, it gets worse again considering that there is work underway to disable SSDs to feed /dev/random. Thus, on a server that is headless but has SSDs we only have interrupts feeding into /dev/random. Thus, getting a full seed of 384 bits is minutes on a headless system will definitely be a challenge in a worst case. > The only reason someone would use this is to comply with the > standard and this is what the standard requires so I don't see > how we can do anything else. I do not see a definite quality requirement of the seed source in SP800-90A. In user space, FIPS validations happily used /dev/urandom where NIST has no concern. Currently, there is a draft interpretation that tightens the issue around /dev/urandom significantly. Therefore, looking into the issue is definitely important. But still, blocking the DRBG right from the start until we have data from /dev/random does not seem helpful either. > > > Furthermore, I fail to see the difference between the current default > > stdrng (krng -- which is just get_random_bytes in disguise). Thus, the > > current situation with the DRBG seeding is not different from the > > non-DRBG use case. > The difference is that krng doesn't have to satisfy any standard. > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
