<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2017 at 18:02, Nemo <span dir="ltr"><<a href="mailto:nemo@self-evident.org" target="_blank">nemo@self-evident.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Ben Laurie <<a href="mailto:benl@google.com">benl@google.com</a>> writes:<br>
<br>
> If you have effective mixing, what is the problem with mixing in<br>
> potentially non-random sources?<br>
<br>
</span>That depends... Might any of those sources know something about your<br>
internal state?<br>
<br>
    <a href="https://blog.cr.yp.to/20140205-entropy.html" rel="noreferrer" target="_blank">https://blog.cr.yp.to/<wbr>20140205-entropy.html</a></blockquote><div><br></div><div>You're already broken if someone knows your internal state.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
But really this is just a detail. In the bigger picture, your question<br>
itself is wrong.<br></blockquote><div><br></div><div>No it isn't.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For cryptographic code, every additional piece of machinery makes the<br>
design harder to analyze rigorously. Every extra line of implementation<br>
is just another opportunity to make a subtle mistake.<br>
<br>
Unnecessary mechanism does not create "defense in depth"; it merely<br>
increases the attack surface.<br></blockquote><div><br></div><div>This is an argument against mixing in _actually_ non-random sources, not _potentially_ non-random sources. If they are also potentially random, then they should be considered.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Since every piece of complexity is a liability, the right question is<br>
not "Does this do any harm?", but rather "Is this necessary?" Each<br>
additional mechanism should contribute in a clear (ideally: provable)<br>
and meaningful (ideally: quantifiable) way to the security of the<br>
system. Otherwise, leave it out. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Again, I humbly request that, whatever clever userspace machinery you<br>
devise, please disable it completely by default on any system with<br>
getrandom() / getentropy() / etc. (Key words are "by default". Sure,<br>
provide APIs for enabling whatever you want... But by default, please<br>
just use the system's provided mechanisms.)<br></blockquote><div><br></div><div>I'm not making the decisions here - and its hard to tell from this thread what decisions are being made!</div><div><br></div><div>A design proposal to comment on would be nice.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
 - Nemo<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/<wbr>mailman/listinfo/cryptography</a></div></div></blockquote></div><br></div></div>