4 ms·
As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code.
by signalsmith 12y ago
As others have mentioned, the JS for the crypto is fetched from the server every time, which is a weak spot because the server could give you duff crypto code.
I've looked at similar things before, and I became very interested in Data URLs. Here's an example that PGP-encrypts files and uploads them to DropBox: https://bitbucket.org/geraintluff/encrypted-drop https://bitbucket.org/geraintluff/encrypted-drop
The idea is that you can fit a very small implementation of SHA-256 as inline JavaScript in an HTML page. This means that you can produce a 1500-character Data URL which loads, SHA-256 verifies and executes the external resources needed to bootstrap your app.
I started a whole module loader based on this concept, so you could do fancier things like async/parallel loading, adding more verification methods (e.g. public key, once that module is loaded) and so on: https://bitbucket.org/geraintluff/caution.js https://bitbucket.org/geraintluff/caution.js
- jamiesonbecker 12y agoThat's pretty slick! (Let's assume that the PRNG in-browser issue is resolved.) Setting far-future expires/forcing long-term caching can help. Even LocalStorage for code can help. Of course, it's still chicken and egg -- and anything can be updated or disabled on the fly w/ HTML anyway at next load. Any of the injection or MITM issues that arise w/ in-browser crypto are similar to those in mobile apps or browser extensions as well, except that you have the chance to modify the app more often, so sticking your crypto code in an app or browser extension is no panacea anyway. Maybe you could combine this concept with http://headjs.com/ http://headjs.com/. It's a great idea.