3 ms·

With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant. [1] http://

With respect to the browser, What’s wrong with in-browser cryptography?[1] and Javascript Cryptography Considered Harmful[2] may still be relevant. [1] http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto [2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

explorigin 11y ago
Both of the articles have some flaws (that Matasano one is really bad/dated actually). Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
- tedunangst 11y ago
  It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.
  - explorigin 11y ago
    The article that I posted, while older, presents a more realistic and objective look at the JS crypto problem. I chose to criticize the matasano article as "dated" because some of the positions it takes are no longer accurate. The older article does not depend on dated information to make its points.
istvan__ 11y ago
This is really good. I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.
lewisl9029 11y ago
Thanks for sharing. I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once. I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?

explorigin 11y ago

Both of the articles have some flaws (that Matasano one is really bad/dated actually). Here's a good one about the problems with JS Crypto: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...

tedunangst 11y ago
It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.
- explorigin 11y ago
  The article that I posted, while older, presents a more realistic and objective look at the JS crypto problem. I chose to criticize the matasano article as "dated" because some of the positions it takes are no longer accurate. The older article does not depend on dated information to make its points.

istvan__ 11y ago

This is really good. I am curious if somebody could mitm the https layer with rogue ca and append more JS to the content. The problem I see as a non-expert with dynamic content that it can't be signed. If we use HTTP as it was intended we could just name the content after the sha(content). That way the client could validate the integrity. The problem with shipping computation to the client side that you lost the integrity verification and opened up the platform to all sorts of vulnerabilities. I guess we should just create a brand new protocol that supports stateful clients, it is network efficient and security is part of the design.

lewisl9029 11y ago

Thanks for sharing. I've come across the Matasano one before and felt it might have been a bit outdated in light of recent efforts with WebCrypto. So it was interesting to see an article critiquing WebCrypto for once. I'm interested in hearing some thoughts on how well WebCrypto would hold up in a local execution environment like Cordova/nw.js/electron rather than in the browser. It seems to me that many of the article's concerns can be addressed by providing the application code in a verifiable package rather than grabbing it over the browser ad-hoc. Am I missing anything?