Hi Robert,
I've put some thought into this topic, and I have a few comments for you
(see below).
On Fri, Mar 18, 2011 at 10:09 AM, Robert Accettura <rob...@accettura.com>wrote:
> I'll prefix this by saying I'm not entirely certain if this should be
> ECMA vs. HTML5 or dual track similar to the "Cryptographically strong
> random numbers"[1] idea floating around. I pitched the idea initially
> via a blog post[2] recently which got a lot more positive feedback
> than I expected. I'll just summarize the more important bits here:
>
> I'd like to propose native cryptography support utilizing a simplified
> API for basic encryption/decryption. Something along the lines of:
> Crypto.AES.encrypt("foo bar", password);
>
> Crypto.AES.decrypt(cryptString, password);
>
> AES obviously being one example algorithm. I'd expect AES to
>
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.
> eventually wane in popularity in favor of something new. SHA-256 and
> other hashing functions could be good as well. SSL is great for
> encrypting data in transit, but data in typically in transit for
> seconds at most but stored on the client (cookies, dom storage) or
> server for extended periods of time in plain text. This would also
> allow for serving some content encrypted from eavesdropping over http
> (assuming a shared key is known by both client and server).
> Encrypting data quickly on the client solves many problems.
>
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 ( http://crypto.stanford.edu/sjcl/ ) for example?
Shabsi
>
> This could be useful beyond just web browsers, node.js comes to mind.
>
> While encryption algorithms could be implemented in JS (and have
> been), doing so natively provides a boost as modern hardware is
> accelerated for certain algorithms such as AES NI[3] as well as
> removes the need for a library. As client side applications get more
> and more complicated and handle more and more data, especially in the
> mobile world where CPU and power consumption are key this would make a
> big difference.
>
> Cite:
> 1.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/thread.html#30241
> 2.
> http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
> 3.
> http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
>
> --
> Robert Accettura
> rob...@accettura.com
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
