Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 1 down vote favorite

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.)

share|improve this question
This question might be better on IT Security. I'll let you decide. If you'd like me to move it there, just flag the question. – mikeazo♦ Sep 27 '12 at 13:22
I decided to close this as it seems you got your answer on stackoverflow (stackoverflow.com/questions/12588249/webcryptoapi-secure-or-not) – mikeazo♦ Oct 12 '12 at 15:04

closed as off topic by mikeazo♦ Oct 12 '12 at 15:04

Questions on Cryptography Stack Exchange are expected to relate to cryptography within the scope defined in the FAQ. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about closed questions here.

1 Answer

up vote 0 down vote

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.

share|improve this answer

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