[Cryptography] where shall we put the random-seed?

[Natanael]

Den 28 dec. 2016 18:13 skrev "Jason Cooper" <cryptography at lakedaemon.net>:


My idea is to leverage the fact that on boot up, the Installer OS
creates many TLS connections to the distros package servers.  Iff those
TLS connections were DHE or ECDHE, then there is an opportunity to
gather some randomness.

Basically, take the (EC)DHE shared secret, run it through an hkdf with
some data from /dev/urandom, and use the output to do a no-credit seed
of /dev/urandom.  The first connection or two will still have crappy
entropy, but after a few connections, the kernel entropy pools will be
in a significantly stronger state.

The difficulty is that it's impossible to quantify.  We don't know how
strong the peer's DHE random key is.  We hope it's strong, but shouldn't
assume a strength.

The shared secret is a) ephemeral, b) short lived, and c) known to only
two devices.  We could trust the peer, but it makes sense to mix in some
crappy data from /dev/urandom so that even the peer doesn't know the
output of the hkdf.  This assumes that the Installer OS was able to
gather a *little* bit of randomness during boot up.  Which isn't too
unreasonable.  A few interrupts, mac addresses, pci config spaces, etc
means there is at least greater than zero once TLS connections start
opening up.

The reason that I like this approach is that there are no changes to
make to the peers.  No changes to the TLS protocol.  The client just
needs a little extra code to accomplish the task.

Once the installer has done it's job, it can just read 512 bytes from
/dev/urandom into /var/lib/*/random-seed and another 512 bytes into
/boot/random-seed.

It should also be noted that this idea would be helpful on embedded
systems where the kernel typically takes 400 to 600 seconds before it
has 128 bits of entropy.  By that point, many TLS connections have been
created.


This doesn't work if your attacker both knows your system and can monitor
all of your network connections.

The reason why - they can (with some limited bruteforce) perfectly predict
your parts of all ephemeral secrets, and thus perfectly simulate your side
of the computations. As a result they can recover the shared session
secrets if they captured all the TLS handshakes.

And we already know that NSA is doing just that as a part of their Quantum
collection of exploits.

Both sides of the network connection needs to have real unpredictable
secrets (keys or ephemeral secrets) for it to work as expected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161228/4680ab6d/attachment.html>