lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20180430002102.GT5965@thunk.org> Date: Sun, 29 Apr 2018 20:21:03 -0400 From: "Theodore Y. Ts'o" <tytso@....edu> To: Dave Jones <davej@...emonkey.org.uk>, Paul Menzel <pmenzel+linux-random-number@...gen.mpg.de>, linux-kernel@...r.kernel.org Subject: Re: Linux messages full of `random: get_random_u32 called from` On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote: > > Why do we continue to print this stuff out when crng_init=1 though ? > > answering my own question, I think.. This is a tristate, and we need it > to be >1 to be quiet, which doesn't happen until.. > > > [ 165.806247] random: crng init done > > this point. Right. What happens is that we divert the first 64 bits of entropy credits directly into the crng state, without initializing the input_pool. So when we hit crng_init=1, the crng has only 64 bits of entropy (conservatively speaking); furthermore, since we aren't doing catastrophic reseeding, if something is continuously reading from /dev/urandom or get_random_bytes() during that time, then the attacker could be able to detremine which one of the 32 states the entropy pool was when the entropy count was 5, and then 5 bits later, poll the output of the pool again, and guess which of the 32 states the pool was in, etc., and effectively keep up with the entropy as it trickles in. This is the reasoning behind catastrophic reseeding; we wait until we have 128 bits of entropy in the input pool, and then we reseed the pool all at once. Why do we have the crng_init=1 state? Because it provides some basic protection for super-early users of the entropy pool. It's essentially a bandaid, and we could improve the time to get to fully initialize by about 33% if we left the pool totally unititalized and only focused on filling the input pool. But given that on many distributions, ssh still insists on initializing long-term public keys at first boot from /dev/urandom, instead of *waiting* until the first time someone attempts to ssh into box, or waiting until getrandom(2) doesn't block --- without hanging the boot --- we have the crng_init=1 hack essentially as a palliative. I view this as working around broken user space. But userspace has been broken for a long time, and users tend to blame the kernel, not userspace.... - Ted
Powered by blists - more mailing lists