Hi Robert,<div><br></div><div> I've put some thought into this topic, and I have a few comments for you (see below).<br><br><div class="gmail_quote">On Fri, Mar 18, 2011 at 10:09 AM, Robert Accettura <span dir="ltr"><<a href="mailto:robert@accettura.com">robert@accettura.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'll prefix this by saying I'm not entirely certain if this should be<br>
ECMA vs. HTML5 or dual track similar to the "Cryptographically strong<br>
random numbers"[1] idea floating around.  I pitched the idea initially<br>
via a blog post[2] recently which got a lot more positive feedback<br>
than I expected.  I'll just summarize the more important bits here:<br>
<br>
I'd like to propose native cryptography support utilizing a simplified<br>
API for basic encryption/decryption.  Something along the lines of:<br>
Crypto.AES.encrypt("foo bar", password);<br>
<br>
Crypto.AES.decrypt(cryptString, password);<br>
<br>
AES obviously being one example algorithm.  I'd expect AES to<br></blockquote><div><br></div><div>AES is a block cipher, and as such, to be used properly for encryption you also need to select a "mode of operation", and other  parameters that are often poorly understood. Furthermore, as you point out below, any given block cipher or hash function may eventually be supplanted by a new standard (as new attacks are discovered, computing power increases, etc.). In general, I am opposed to the idea of exposing such primitives as the primary API for any crypto library, and I think most cryptographers would agree. Instead, the primitives should only exposed for users that absolutely have to do something custom or interoperable etc. The primary API should simply "do the right thing", and give you access to a symmetric key secure encoding/decoding procedure that implements a secure authenticated encryption mechanism. Ditto for public key crypto, although there things get a bit more complex. I think you would accomplish a lot more for security in practice, if you follow this approach.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
eventually wane in popularity in favor of something new.  SHA-256 and<br>
other hashing functions could be good as well.  SSL is great for<br>
encrypting data in transit, but data in typically in transit for<br>
seconds at most but stored on the client (cookies, dom storage) or<br>
server for extended periods of time in plain text.  This would also<br>
allow for serving some content encrypted from eavesdropping over http<br>
(assuming a shared key is known by both client and server).<br>
Encrypting data quickly on the client solves many problems.<br></blockquote><div><br></div><div>I'm not convinced that this use case, or any other use case I could think of for the web (with the possible exception of DRM/encryption on streaming media), would really benefit from speed. On the whole, you would most likely be encrypting fairly small quantities of data, and any larger quantities of data would typically be handled in a context where the encryption/decryption can even be done asynchronously. Even on a mobile phone, a few blocks of AES could probably done in pure JS without noticeable delay. Have you done any experiments with SJCL ( <a href="http://crypto.stanford.edu/sjcl/">http://crypto.stanford.edu/sjcl/</a> ) for example?</div>

<div><br></div><div>Shabsi</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This could be useful beyond just web browsers, node.js comes to mind.<br>
<br>
While encryption algorithms could be implemented in JS (and have<br>
been), doing so natively provides a boost as modern hardware is<br>
accelerated for certain algorithms such as AES NI[3] as well as<br>
removes the need for a library.  As client side applications get more<br>
and more complicated and handle more and more data, especially in the<br>
mobile world where CPU and power consumption are key this would make a<br>
big difference.<br>
<br>
Cite:<br>
1.  <a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/thread.html#30241" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/thread.html#30241</a><br>
2.  <a href="http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/" target="_blank">http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/</a><br>
3.  <a href="http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/" target="_blank">http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/</a><br>


<font color="#888888"><br>
--<br>
Robert Accettura<br>
<a href="mailto:robert@accettura.com">robert@accettura.com</a><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</font></blockquote></div><br></div>