<font size=2 face="sans-serif">If the desired outcome is security you
must generate instance unique keys and elegant software design alone is
simply not enough to achieve that. </font><br><br><font size=2 face="sans-serif">And I didn't say solve below I said
mitigate. </font><br><font size=2 face="sans-serif">You can't solve the problem of someone
using already created keys in multiple VM's. </font><br><font size=2 face="sans-serif">But you can and should reduce the chances
that someone will create them from a fresh keygen because that simply can't
be mitigated anywhere else but in your code.</font><br><br><font size=2 face="sans-serif">Simillar issues exist with fork(), and
again, you should make efforts to mitigate that risk because the user can't.</font><br><br><font size=2 face="sans-serif">Magic fairy dust like (/dev/hwrng) undoubtedly
helps where it exists, but you still have to apply it correctly to achieve
the desired outcome.</font><br><br><font size=2 face="sans-serif">Peter</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">John Denker via openssl-dev
<openssl-dev@openssl.org></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"openssl-dev@openssl.org"
<openssl-dev@openssl.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">28/06/2017 12:19</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openssl-dev]
Work on a new RNG for OpenSSL</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"openssl-dev"
<openssl-dev-bounces@openssl.org></font><br><hr noshade><br><br><br><tt><font size=2>On 06/27/2017 06:41 PM, Peter Waltenberg wrote:<br><br>> Consider most of the worlds compute is now done on VM's where images
are <br>> cloned, duplicated and restarted as a matter of course. Not vastly
<br>> different from an embedded system where the clock powers up as 00:00
<br>> 1-Jan, 1970 on each image. If you can trust the OS to come up with
unique <br>> state each time you can rely solely on the OS RNG - well provided
you <br>> reseed often enough anyway, i.e. before key generation. That's also
why <br>> seeding a chain of PRNG's once at startup is probably not sufficient
here.<br><br>That is approximately the last thing openssl should be<br>fussing over. There is a set of problems there, with a<br>set of solutions, none of which openssl has any say over.<br><br>===> The VM setup should provide a virtual /dev/hwrng <===<br><br>Trying to secure a virtual machine without a virtual hwrng<br>(or the equivalent) is next to impossible. There may be<br>workarounds, but they tend to be exceedingly locale-specific,<br>and teaching openssl to try to discover them would be a<br>tremendous waste of resources.<br><br>So stop trying to operate without /dev/hwrng already.<br><br>It reminds me of the old Smith & Dale shtick:<br> -- Doctor, doctor, it hurts when I do *this*.<br> -- So don't do that.<br>-- <br>openssl-dev mailing list<br>To unsubscribe: </font></tt><a href="https://mta.openssl.org/mailman/listinfo/openssl-dev"><tt><font size=2>https://mta.openssl.org/mailman/listinfo/openssl-dev</font></tt></a><tt><font size=2><br><br></font></tt><br><br><BR>