[openssl-dev] Work on a new RNG for OpenSSL
Peter Waltenberg
pwalten at au1.ibm.com
Wed Jun 28 22:13:20 UTC 2017
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 <cory at lukasa.co.uk>
To: openssl-dev at 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-bounces at openssl.org>
> On 28 Jun 2017, at 04:00, Paul Dale <paul.dale at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170629/3ef082b2/attachment-0001.html>
More information about the openssl-dev
mailing list