[openssl-users] PRNG is not seeded

[Jochen Bern]

On 06/06/2018 09:12 PM, openssl-users-request at openssl.org digestributed:
> Date: Wed, 6 Jun 2018 16:12:59 +0000
> From: Michael Wojcik <Michael.Wojcik at microfocus.com>
> 
>> Hence my solution of using a hardware TRNG shared over the
>> network with devices that lack the ability to have one added
>> locally.
> 
> Yes, I think that's a good approach. It reduces the attack surface,
> since the client device can connect to the entropy-gathering device
> with considerable assurance (it can be configured with a pinned CA
> or PSK, etc), and at startup can use some entropy saved from the
> previous run. An attacker in a privileged position could try active
> attacks like a DoS against the connection to the entropy server, but
> a (more dangerous) passive attack looks very difficult.

Speaking of attack scenarios, I refreshed my info after this discussion
and wondered how likely it is that someone (in a Linux world) would want
to attack the entropy *sources* directly. A manipulated source's effect
on applications (that read from /dev/random) would be somewhat limited
due to the kernel folding in other sources as well (memento Linus'
statement about RDRAND), and due to the fact that *many* consumers read
from it (you cannot predict who gets which part of your manipulated
entropy).

For comparison, imagine someone attacking the kernel and manipulating
the /dev/random driver so that it feeds predictable sequences to the
targets (processes running executables "httpd", "gpg", etc.) but real
pool data to all other consumers. Presto, a subverted system that still
gets a clean bill of health from rngtest, ent, dieharder, or whatever
other analyzer you care to try ...

... by which I mean to ask, since I read a quest for suitable
entropy-distribution protocols between the lines here, maybe there is
something to be said in favor of signed-at-source chunks of entropy
being forwarded *through* the kernel unchanged, and leaving the
trust-based selection of sources and final folding to the individual
applications?

> And it's practical for real-world data centers; implementation and
> equipment costs are low.

[has been trying to acquire a better *NTP* source than public unsigned
servers in certain data centers for 8+ years] :-C

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180606/ef1021b4/attachment.bin>