Hacker News Reader

Comment by michaelsbradley | Hacker News Reader

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

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

View on HN

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

It's curious that you follow up a "really dated" article from 2011 with an article from... 2010.

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.

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.

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?

Reply on news.ycombinator.com