<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">Den 28 dec. 2016 18:13 skrev "Jason Cooper" <<a href="mailto:cryptography@lakedaemon.net" target="_blank">cryptography@lakedaemon.net</a>>:<blockquote class="m_2261709011334518796quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My idea is to leverage the fact that on boot up, the Installer OS<br>
creates many TLS connections to the distros package servers.  Iff those<br>
TLS connections were DHE or ECDHE, then there is an opportunity to<br>
gather some randomness.<br>
<br>
Basically, take the (EC)DHE shared secret, run it through an hkdf with<br>
some data from /dev/urandom, and use the output to do a no-credit seed<br>
of /dev/urandom.  The first connection or two will still have crappy<br>
entropy, but after a few connections, the kernel entropy pools will be<br>
in a significantly stronger state.<br>
<br>
The difficulty is that it's impossible to quantify.  We don't know how<br>
strong the peer's DHE random key is.  We hope it's strong, but shouldn't<br>
assume a strength.<br>
<br>
The shared secret is a) ephemeral, b) short lived, and c) known to only<br>
two devices.  We could trust the peer, but it makes sense to mix in some<br>
crappy data from /dev/urandom so that even the peer doesn't know the<br>
output of the hkdf.  This assumes that the Installer OS was able to<br>
gather a *little* bit of randomness during boot up.  Which isn't too<br>
unreasonable.  A few interrupts, mac addresses, pci config spaces, etc<br>
means there is at least greater than zero once TLS connections start<br>
opening up.<br>
<br>
The reason that I like this approach is that there are no changes to<br>
make to the peers.  No changes to the TLS protocol.  The client just<br>
needs a little extra code to accomplish the task.<br>
<br>
Once the installer has done it's job, it can just read 512 bytes from<br>
/dev/urandom into /var/lib/*/random-seed and another 512 bytes into<br>
/boot/random-seed.<br>
<br>
It should also be noted that this idea would be helpful on embedded<br>
systems where the kernel typically takes 400 to 600 seconds before it<br>
has 128 bits of entropy.  By that point, many TLS connections have been<br>
created.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">This doesn't work if your attacker both knows your system and can monitor all of your network connections. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">And we already know that NSA is doing just that as a part of their Quantum collection of exploits.</div><div dir="auto"><br></div><div dir="auto">Both sides of the network connection needs to have real unpredictable secrets (keys or ephemeral secrets) for it to work as expected.  </div><div class="gmail_extra" dir="auto"></div></div>