I was going through HN comments for the ShowHN Graphite post and saw a reply about the pitfalls of client side JS encryption. I wanted to understand this better so I went and read the original critique from 2011:
It seems that Blockstack sidesteps the issue the way a plug-in would–because it’s external to the browser, it has it’s own CSPRNG functionality that doesn’t rely upon a js method in the browser that is vulnerable to being redefined at any point.
Is that understanding correct?
There are a couple things Blockstack does that negates the concerns in that article:
Your identity wallet and master private key are controlled by a locally-running node.js process. The Blockstack Browser code is served locally, so none of the concerns about remote code injection apply. The crypto code for this is downloaded once when you install it.
Each application gets a per-app private key that is passed to the application by the Blockstack Browser (e.g. as a string on a http://localhost URL).
While it is possible for a malicious Blockstack application to do things like divulge the app-specific private key, exfiltrate data you upload to it, and use attacker-chosen keys instead of the one handed to it by the Blockstack Browser, the application cannot get the keys for your other applications and cannot alter other applications’ state. This is all a consequence of the fact that the app server can serve you malicious code (generally an unsolvable problem). However, we are working on making it so the developer has to sign each version of the app and broadcast it via Blockstack’s naming system, as described here: Server-Dependent Code - “Exposed” Microservice Cloud Concept. This would make it impossible for malicious app servers to silently inject malicious code.