Morning.��<br><div><br></div><div>Designing RNGs for crypto use is a finicky thing and making so much as a single mistake can render the entire crypto system useless.��</div><div><br></div><div>If you&#39;re just doing this for post hangover fun then cool :)��</div><div><br></div><div>If you&#39;re serious about it then I&#39;d suggest��finding<span></span>��an existing team and look to contribute to their efforts.��</div><div><br></div><div>These guys are cool.��</div><div><br></div>OpenRNG<br><div><a href="https://m.youtube.com/watch?v=jiy1rlKdBo8">https://m.youtube.com/watch?v=jiy1rlKdBo8</a><br></div><div><br>as are these guys.��</div><div>CrypTech<br><a href="https://cryptech.is/">https://cryptech.is/</a></div><div><br></div><div><br></div><div>Both those projects would love collaborators and have the technical ability to peer review contributions��</div><div><br></div><div>Have fun!</div><div><br></div><div>Dean<br><br>On Saturday, 23 May 2015, Nathan Ward &lt;<a href="mailto:nznog@daork.net">nznog@daork.net</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
As we all know, random numbers are an important part of cryptography, which is required for tools that are important to network operators like the widely deployed RPKI. Most systems today generate random numbers using a PRNG, rather than a dedicated hardware random number generator. A PRNG is only as good as its entropy source - if you have a small amount of entropy, an attacker can start to predict the output of your system���s PRNG, which is obviously bad.<br>
<br>
There are a number of existing tools for generating entropy:<br>
- HAVEGE implementations (i.e. <a href="http://www.issihosts.com/haveged/" target="_blank">http://www.issihosts.com/haveged/</a>)<br>
- Audio/video sources (audio_entropyd and video_entropyd)<br>
- Some other things like mouse/keyboard input (i.e. when you wiggle your mouse over that window in whatever that app was that generated keys, puttygen maybe?)<br>
- Network interrupts is also a common source<br>
<br>
A week or two back I was a little hungover and didn���t want to do any real work, and decided to write my own entropy harvesting tool, and have the code available at the below URL:<br>
<a href="https://github.com/nward/trueentropy" target="_blank">https://github.com/nward/trueentropy</a><br>
<br>
I strongly encourage you NOT to run this on production systems, until it has been certified (a good standard to shoot for would be NIST SP 800-90B perhaps), but I would like to get feedback, so please read the code and suggest improvements. Perhaps you have some additional sources of entropy data that would be useful.<br>
<br>
I would particularly like a good way to ���boil down��� the entropy generated. The Linux kernel by default can take up to 4096 bits, and this provides far, far more than that, which just seems like a bit of overkill. Please feel free to submit pull requests with ideas for that - it would be a great project to learn a bit of Python.<br>
<br>
Generally, entropy should not be sourced from a system you don���t control, or sourced over a network you don���t control, for obviously reasons. However, the quality of the data is so good in this case that I believe it negates those concerns. The data is also fetched with HTTPS, so as long as the source doesn&#39;t also starting using this as their entropy source (known as entroception) we should be OK - see my recommendation about production systems.<br>
<br>
--<br>
Nathan Ward<br>
(opinions all my own, blah blah blah)<br>
_______________________________________________<br>
NZNOG mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;NZNOG@list.waikato.ac.nz&#39;)">NZNOG@list.waikato.ac.nz</a><br>
<a href="http://list.waikato.ac.nz/mailman/listinfo/nznog" target="_blank">http://list.waikato.ac.nz/mailman/listinfo/nznog</a><br>
</blockquote></div>