1
$\begingroup$

This is about the new W3 WebcryptoAPI draft standard.

Here is a post by one of it's authors

https://plus.google.com/u/0/105761279104103278252/posts/CSwVZ1RUijo

It says its in part trying to change the "Javascript Cryptography Considered Hamrful" problem. However if you look at the "Javascript Cryptography Considered Hamrful" article - http://www.matasano.com/articles/javascript-cryptography/ - it seems as if most of the problems still remain unsolved. The only problem solved is that you won't have hand coded cryptographic functions in javascript - these will be provided by the browser. However, the remaining problems still remain.

Your thoughts?

(I originally asked this at stackoverflow but did not receive any useful response.)

$\endgroup$
0
$\begingroup$

Personally I believe that it could be done properly and address all (or at least some) of the concerns.

Remember what the WebCryptoAPI is:

This specification describes a JavaScript API for performing basic cryptographic operations in web applications, such as hashing, signature generation and verification, and encryption and decryption. Additionally, it describes an API for applications to generate and/or manage the keying material necessary to perform these operations. Key storage is provided for both temporary and permanent keys. Access to keying material is contingent on the same origin policy. Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications.

A lot of the concerns are related to how the code is distributed, hijacking the javascript/security of javascript engine, etc.

Well, for this particular standard, the code is distributed with the browser, not over the http socket. So at least the crypto algorithms should be safe. Furthermore, that would make it difficult for someone to say override the crypto code with attacker supplied code as browser checks can be added.

Hijacking of the content delivered by the HTTP server (say through XSS) to disable crypto or steal crypto keys is a concern. But, it is just a symptom of a larger problem.

It definitely attempts to solve some of the other problems such as key generation, key storage, etc.

A lot of this will depend on actual implementations, however.

| improve this answer | |
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.