1. Nothing like this is ever safe; the server can surreptitiously feed you JS that will fatally compromise your encryption.
2. This one is even worse, because it loads scripts from CDNs, all of which can compromise the encryption on the page.
3. If you're going to put Google Analytics on a page that purports to encrypt data clientside, you might as well just build a front-end to Google Docs, because you've given Google access to the content of the pages anyways. (I think a simplified Google Docs front-end is a fine thing to build, more useful for security than "clientside" encryption).
4. You're encrypting with unauthenticated CBC mode, which is obviously insecure.
5. It's unsafe to compress before encrypting; doing so creates traffic-analytic side channels. There's a whole thread of TLS vulnerabilities stemming from compression occurring at various points of the web stack.
If you really want to build something like this, my recommendation is:
1. Switch from a web page to a web extension, which will obvious most of the serverside dependency problem.
2. Stop using CryptoJS, which is extraordinarily difficult to use "properly", and use a Javascript NaCL implementation instead.
Don't bother. You won't gain any meaningful security, and you'll be using the same error-prone, outmoded constructions. Even if you had built this application in perfect, error-proof Haskell, it would still be insecure because of the way you're using AES. Adopt a credible NaCL library.
Really though, if you're interested in crypto, I strongly urge you not to go the route of trying to build crypto applications. The crypto apps people really need are extremely hard to build safely.
A better place to start with crypto is to learn how to break it. The cryptopals challenges are programming intensive and don't have any prerequisites; or, check out LVH's Crypto 101.
I've implemented all points that @tptacek mentioned (except the web extension, that will be a future update), and will also activate HSTS when I feel comfortable with the server setup.
I switched from CryptoJS to TweetNaCl which seemed fit to purpose, and also moved all CDN depencencies locally as well as removed Google Analytics :)
I really appreciate how well you took the feedback and how quickly you acted on it. Refreshing to see such interactions online these days, make me think of times when the web felt more... amateur? Less pretentious? I fail to capture the feeling. Anyhow, thanks for the service. Will give it a try :)
1. Nothing like this is ever safe; the server can surreptitiously feed you JS that will fatally compromise your encryption.
2. This one is even worse, because it loads scripts from CDNs, all of which can compromise the encryption on the page.
3. If you're going to put Google Analytics on a page that purports to encrypt data clientside, you might as well just build a front-end to Google Docs, because you've given Google access to the content of the pages anyways. (I think a simplified Google Docs front-end is a fine thing to build, more useful for security than "clientside" encryption).
4. You're encrypting with unauthenticated CBC mode, which is obviously insecure.
5. It's unsafe to compress before encrypting; doing so creates traffic-analytic side channels. There's a whole thread of TLS vulnerabilities stemming from compression occurring at various points of the web stack.
If you really want to build something like this, my recommendation is:
1. Switch from a web page to a web extension, which will obvious most of the serverside dependency problem.
2. Stop using CryptoJS, which is extraordinarily difficult to use "properly", and use a Javascript NaCL implementation instead.
Thanks for the feedback! I will definitely address your points, and I really appreciate the constructive criticism :)
Wouldn't it make even more sense to use the Web Crypto API instead of any JS crypto library loaded from the server?
Yes, that would probably make sense for the browsers that supports it. Which seems to be mostly everyone except IE.
It will be fixed in the next update!
Don't bother. You won't gain any meaningful security, and you'll be using the same error-prone, outmoded constructions. Even if you had built this application in perfect, error-proof Haskell, it would still be insecure because of the way you're using AES. Adopt a credible NaCL library.
Really though, if you're interested in crypto, I strongly urge you not to go the route of trying to build crypto applications. The crypto apps people really need are extremely hard to build safely.
A better place to start with crypto is to learn how to break it. The cryptopals challenges are programming intensive and don't have any prerequisites; or, check out LVH's Crypto 101.
I took your advice from the other comment and started using TweetNaCl.js which had some pretty good endorsements :)
I’ll definitely check out some more sources on crypto in general. Thanks for the input, really!
Also - regarding your second #1, are we talking about something like a Chrome extension?
Yep.
I've implemented all points that @tptacek mentioned (except the web extension, that will be a future update), and will also activate HSTS when I feel comfortable with the server setup.
I switched from CryptoJS to TweetNaCl which seemed fit to purpose, and also moved all CDN depencencies locally as well as removed Google Analytics :)
I really appreciate how well you took the feedback and how quickly you acted on it. Refreshing to see such interactions online these days, make me think of times when the web felt more... amateur? Less pretentious? I fail to capture the feeling. Anyhow, thanks for the service. Will give it a try :)
Snyggt! I really like the UX and layout. Clean, simple and at the same time really fresh and modern. Would love to see any other projects you’ve made!
Thanks! It’s mostly Bootstrap so I shouldn’t really take credit :)
Have a look at https://github.com/picotorrent/picotorrent for one of the more popular projects I run!