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

[Jason Cooper]

Hi Natanael,

On Wed, Dec 28, 2016 at 08:54:02PM +0100, Natanael wrote:
> 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.

A backbone monitor doesn't see your local connections.  Even a couple of
those would throw them off.

Also, perhaps I wasn't explicit, but this proposal was never intended to
be a *sole* source of randomness.  Rather, to augment existing sources,
especially when they are slow or lean (embedded systems, VMs).

> 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.

How is that different from the same situation without my proposal?

Given an environment with multiple slow, non-ideal sources of entropy,
why not include a free one that's just sitting there?  It makes the
system stronger with minimal hassle.

Is it non-ideal?  Sure.  Just as you outlined.  But it doesn't make the
situation any worse, and will quite often help.

Additionally, if this were deployed on a LiveCD, I wouldn't feel the
need to 'ssh hostA "dd if=/dev/urandom count=1" | dd of=/dev/urandom' to
several hosts on my local network running baremetal with long uptimes
before creating disk keys, random-seed, etc.  Instead, I would just
count the number of DHE connections (local and remote) before continuing
with the install.

thx,

Jason.