<br><br><div class="gmail_quote">On Mon, Feb 14, 2011 at 12:01 PM, Shabsi Walfish <span dir="ltr">&lt;<a href="mailto:shabsi@google.com">shabsi@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Mon, Feb 14, 2011 at 11:31 AM, Adam Barth <span dir="ltr">&lt;<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote">On Mon, Feb 14, 2011 at 8:31 AM, Mark S. Miller <span dir="ltr">&lt;<a href="mailto:erights@google.com" target="_blank">erights@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div>On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth <span dir="ltr">&lt;<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>That&#39;s a pretty long time horizon.  You&#39;re going to start discussing</div></div>
it in 2-4 months?  That seems a bit overwrought for what amounts to<br>
four lines of code.<br></blockquote><div><br></div></div><div>The committee meets once every two months. Between meetings, we discuss things on es-discuss, so please do.</div><div><br></div><div>What are the four lines of code?</div>




<div>
<div></div></div></div></blockquote></div><br></div><div><a href="http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp" target="_blank">http://trac.webkit.org/browser/trunk/Source/WebCore/page/Crypto.cpp</a></div>


<div><br></div>

<div>On Mon, Feb 14, 2011 at 8:40 AM, Boris Zbarsky <span dir="ltr">&lt;<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">


<div>

<div>On 2/14/11 11:31 AM, Mark S. Miller wrote:<br></div></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">


<div>

<div>On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth &lt;<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a><br></div></div><div><div>&lt;mailto:<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a>&gt;&gt; wrote:<br>




<br>   That&#39;s a pretty long time horizon.  You&#39;re going to start discussing<br>   it in 2-4 months?  That seems a bit overwrought for what amounts to<br>   four lines of code.<br></div></div></blockquote><br><div>


For what it&#39;s worth, it&#39;s a lot more than 4 lines of code in Gecko, because we don&#39;t have an existing source of strong randomness in Spidermonkey.  It&#39;d be about that much code in the DOM, where we could pass the buck to NSS, but for Spidermonkey it would take a good bit more work.</div>


</blockquote>

<div><br></div>Similarly, the WebKit implementation just passes the buck to the WTF layer, which already knows how to fill a void* with n cryptographically random bytes.  The implementation will be similarly trivial in most applications that link with OpenSSL or NSS or that run on Mac, Linux, or Windows.</div>




<div><br><div class="gmail_quote">On Mon, Feb 14, 2011 at 10:05 AM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">




<div><div></div><div><div>On Feb 14, 2011, at 8:40 AM, Boris Zbarsky wrote:<br>&gt; On 2/14/11 11:31 AM, Mark S. Miller wrote:<br></div><div>&gt;&gt; On Mon, Feb 14, 2011 at 2:47 AM, Adam Barth &lt;<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a><br>


</div><div>

&gt;&gt; &lt;mailto:<a href="mailto:w3c@adambarth.com" target="_blank">w3c@adambarth.com</a>&gt;&gt; wrote:<br>&gt;&gt;<br>&gt;&gt;    That&#39;s a pretty long time horizon.  You&#39;re going to start discussing<br>&gt;&gt;    it in 2-4 months?  That seems a bit overwrought for what amounts to<br>




&gt;&gt;    four lines of code.<br>&gt;<br></div><div>&gt; For what it&#39;s worth, it&#39;s a lot more than 4 lines of code in Gecko, because we don&#39;t have an existing source of strong randomness in Spidermonkey.  It&#39;d be about that much code in the DOM, where we could pass the buck to NSS, but for Spidermonkey it would take a good bit more work.<br>




<br></div></div></div><div>Not really. We use callback-style APIs to delegate such chores as l10n to the embedding, and the same can be done for randomness-hunting. It&#39;s just interfacing, or buck-passing -- but I&#39;m still wondering what magical four lines of code provide useful lower bounds on bits of entropy in WebKit. Is this just non-interoperable delegation to the host OS?<br>




</div></blockquote><div><br></div><div>What&#39;s non-interoperable about filling an ArrayBuffer with random bytes?  I&#39;m not sure I understand your question.</div><div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">




Adam, I like moving fast (but beware, that&#39;s how JS and the DOM were created), but we need a cross-browser spec of some kind, even if we all add crypto.getRandomValues quickly. The original y2k-buggy, cloned-from-java.util.Date JS Date object of 1995 required a lot of work for ES1 to remove OS dependencies that made for interop hell.<br>




</blockquote><div><br></div></div><div>In this case, the API is several order of magnitude simpler than Date.  The choices to make roughly boil down to the name of the function, which types to support, and what sorts of exceptions to throw in which error cases.</div>


<div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">




For a core language standard, we would want some kind of minimum quality guarantee on the randomness.<br></blockquote><div><br></div></div><div>I&#39;m not sure that&#39;s possible without either allowing the API to block for arbitrary periods of time or to fail.  Assuming we want a non-blocking, non-failing API, we can&#39;t make any guarantees about the quality of the randomness.  In that sense, crypto.getRandomValues is &quot;best effort.&quot;</div>


</div></div></blockquote><div><br></div></div></div><div>I don&#39;t think its necessary to use &quot;best effort&quot; if you want something that is effectively non-blocking... what you need to do is preemptively gather a _small_ amount of real entropy on startup (say, 160 bits worth) and then use a cryptographic PRNG to generate whatever you need based on that seed... the PRNG would be pretty darn fast, so you wouldn&#39;t have to block forever after. Only the initial seeding needs to be done via a call to the OS that might block, and if that can be done asynchronously at startup time odds are good it will be a non-issue on most all platforms. Whatever you do, my advice is to combine entropy in the seed pool via XOR (assuming you do any entropy combining), since various combinations of append/prepend/etc. always </div>

</div></blockquote><div><br></div><div>Sorry, as David pointed out to me, this was not stated correctly... What I meant to say is, hash the entropy sources you are combining out to 160 bits, then XOR the 160 bit outputs together in the pool. I think David may still disagree with this advice though, so I&#39;ll leave it to him to comment. ;)</div>

<div><br>Shabsi</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>lead to problems.</div>
<div><br></div><font color="#888888"><div>Shabsi</div></font><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote">



<div><br></div><div>Obviously, a blocking API is in appropriate for the browser setting.  There&#39;s certainly a place for failing randomness sources (e.g., analogous to /dev/random versus /dev/urandom, although /dev/random is blocking rather than failing).  The need just isn&#39;t as dire, in my view.  I&#39;d certainly be happy if ECMAScript came along in six months or a year with a nice cryptographic library, including a variety of random generators (e.g., perhaps seedable, failing, and with algorithmic agility).  However, I&#39;m disinclined to wait on the basic best-effort PRNG for that to happen.</div>


<div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">




Quick thought on the name: to avoid vagueness and the &quot;why not wider int or even float element type&quot; questions that have already come up, call the method getRandomBytes.<font color="#888888"><br></font></blockquote>




<div></div></div></div></div><div><br></div><div>I added support for all the integer ArrayBuffer types, so getRandomBytes isn&#39;t a particularly accurate name.</div><div><br></div><font color="#888888"><div>Adam</div><div>


<br>

</div>
</font></blockquote></div></div><br>
</blockquote></div><br>