A Criticism of JavaScript Cryptography

40 views
Skip to first unread message

Trishank Karthik Kuppusamy

unread,
Jun 18, 2014, 8:16:53 PM6/18/14
to theupdateframework
We're indirectly on Hacker News. Justin, you will find this interesting.

Brendan McMillion claims that the security of in-browser cryptography can be analyzed in the same manner as software repositories. McMillion argues that Thomas Ptacek, in his article entitled "Javascript Cryptography Considered Harmful", makes the fallacy of comparing HTTP with TUF.

https://bren2010.github.io/jekyll/update/2014/06/17/javascript-crypto.html

Basically, McMillion argues that some people conflate their threat models when they argue against in-browser cryptography.

Ptacek rebuts McMillion here: https://news.ycombinator.com/item?id=7911887

I'm not on any side of the argument on in-browser cryptography; I'm simply pointing out the arguments, and noting that one of them considers the threat model to be similar to that of TUF.

Tony Arcieri

unread,
Jun 18, 2014, 8:18:59 PM6/18/14
to Trishank Karthik Kuppusamy, theupdateframework
So yeah, that was my blog post, and I think his interpretation overplayed the "not good as TUF" angle when my real point was the difficulty of building "trust no one" software in an ephemeral and fleeting environment like the web.
--
Tony Arcieri

Trishank Karthik Kuppusamy

unread,
Jun 18, 2014, 8:42:24 PM6/18/14
to Tony Arcieri, theupdateframework
I think I see what you're saying; that the Matasano post argues that a lot of cryptography in web apps is flawed because the code is delivered insecurely (over plain HTTP):


Furthermore, TLS + HTTP = HTTPS does not solve the whole problem because the threat model (implicitly) specifies that the web server cannot be trusted with the user's (unencrypted) data. That indirectly means that the server cannot be trusted with delivering a correct implementation of cryptography, so no amount of secure delivery of the web application is going to solve the problem.

Therefore, perhaps critics of cryptography in web apps argue that the threat model should be much stronger, as in the web server is trusted as little as possible (whatever that means)? This may be why they refer to works on searchable encryption.

Tony Arcieri

unread,
Jun 18, 2014, 8:47:35 PM6/18/14
to Trishank Karthik Kuppusamy, theupdateframework
One interesting recent advance in this area is Subresource Integrity:


This allows a parent page to specify a content hash (using the ni:/// URI scheme) for the subresources it references. If these content hashes were validated, there wouldn't be any need for HTTPS on the subresources (of course we still need to trust the parent page)

With this approach, an HTML application begins to look like a Merkle tree of documents. Of course, to really be interesting we'd need to have some way of flipping on hard failures for if all of the subresources don't have content hashes. Also, having some way to sign the root document would be nice...

--
Tony Arcieri

Trishank Karthik Kuppusamy

unread,
Jun 18, 2014, 9:01:37 PM6/18/14
to Tony Arcieri, theupdateframework
That's interesting, thanks, I didn't know about it.

They seem to rely on TLS to sign the root document (http://www.w3.org/TR/2014/WD-SRI-20140318/#insecure-channels-remain-insecure-1).

Trishank Karthik Kuppusamy

unread,
Jun 19, 2014, 12:44:39 PM6/19/14
to Tony Arcieri, theupdateframework
Thai Duong (of BEAST and CRIME fame) weighs in on the debate: http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-is-useful.html
Reply all
Reply to author
Forward
0 new messages