Debian also screwed up here at one point and the SSH keys for Debian installs came from a very small subset of keys. This CLASS of problem is common and it's something you need to make efforts to avoid. And again, it is something you need to address as far as you can because you simply can't rely on the users of your software to be able to do better.
Seeding is a hard problem as is using the seed material correctly. The overall objective is security, security requires instance unique keys, keys that aren't trivially guessed. Quite a few of the suggestions made so far would compromise that. It's a very different problem from generating good pseudo-random sequences and by it's nature doesn't lend itself well to clean and elegant solutions. Peter From: Cory Benfield <c...@lukasa.co.uk> To: openssl-dev@openssl.org Date: 28/06/2017 17:15 Subject: Re: [openssl-dev] Work on a new RNG for OpenSSL Sent by: "openssl-dev" <openssl-dev-boun...@openssl.org> > On 28 Jun 2017, at 04:00, Paul Dale <paul.d...@oracle.com> wrote: > > > Peter Waltenberg wrote: >> The next question you should be asking is: does our proposed design mitigate known issues ?. >> For example this: >> http://www.pcworld.com/article/2886432/tens-of-thousands-of-home-routers-at-risk-with-duplicate-ssh-keys.html > > Using the OS RNG won't fix the lack of boot time randomness unless there is a HRNG present. > > For VMs, John's suggestion that /dev/hwrng should be installed is reasonable. > > For embedded devices, a HRNG is often not possible. Here getrandom() (or /dev/random since old kernels are common) should be used. Often /dev/urandom is used instead and the linked article is the result. There are possible mitigations that some manufacturers include (usually with downsides). When you say “the linked article”, do you mean the PCWorld one? Because that article doesn’t provide any suggestion that /dev/urandom has anything to do with it. It is at least as likely that the SSH key is hard-coded into the machine image. The flaw here is not “using /dev/urandom”, it’s “exposing your router’s SSH access on the external side of the router”, plus the standard level of poor configuration done by shovelware router manufacturers. Cory -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
