5 ms·

Good on you for having a list of known weaknesses, but here's the one that really makes this completely unsafe: The server dictates what's run on the page, and

by daeken 13y ago

Good on you for having a list of known weaknesses, but here's the one that really makes this completely unsafe: The server dictates what's run on the page, and thus can access the plaintext data in any way it sees fit. The trust model is fundamentally broken in client-side crypto of this nature. Edit with two more thoughts: 1) Even if you trust the person running the service, how much do you trust the other users (who may be using stored XSS to compromise your data)? How much do you trust the hosting service behind it, if there is one? 2) Am I the only one that finds it massively irresponsible to not have a huge flashing "DO NOT TRUST THIS UNTIL IT'S BATTLE HARDENED" sign over it? This goes for just about every project of this nature. Edit with a final thought: Most of the time, we think in terms of "relative goodness". A good car is better than a bad car, but a bad car is still better than no car at all. This logic completely breaks when it comes to crypto. Simply put, bad crypto (and bad implementations) when released on the world put lives at risk. This should be taken seriously. It's one thing to build a project for learning (and please, please do!) but cover every friggin' surface you can with disclaimers.

alainmeier 13y ago
Thanks, and that is absolutely true. That's why it's open source: I want people to host their own version if they don't trust me https://github.com/alainmeier/cryptonote https://github.com/alainmeier/cryptonote
- daeken 13y ago
  But if you need to trust the server (and you do), then the client-side encryption is 100% pointless. You might as well encrypt on the server with safe, sane, battle-hardened code. At the end of the day, XSS, rogue hosts, etc can own this even if the person "running the show" doesn't want it to happen. Edit: I note that you now link to nadim's response to http://www.matasano.com/articles/javascript-cryptography&#x2F http://www.matasano.com/articles/javascript-cryptography&#x2...; -- you reaaaaally should consider linking to the original, or perhaps to https://news.ycombinator.com/item?id=5768837 https://news.ycombinator.com/item?id=5768837 wherein that article is torn to shreds. JS cryptography is very, very dangerous.
alainmeier 13y ago
Hm, yes, added a warning message, good idea. As for your other thoughts, I completely agree. It's a work-in-progress and I figured the best way to figure out what's wrong is to learn from others. Edit: Also added a link to that discussion next to Nadim's post.
- daeken 13y ago
  Awesome, glad to hear it!
rmrfrmrf 13y ago
If you're that paranoid, you shouldn't be using a hosted service at all. There could be a guy right outside your house intercepting your cable line and filtering all traffic to and from cryptonote.org and routing it to his own instance of the app. That doesn't mean that cryptonote is responsible for that happening.
- daeken 13y ago
  This is everything that is wrong with cryptography and privacy. Simply put, if your data is important enough to use cryptography on it, why would you want to use crypto that is broken by design? The whole point of a well-designed, well-implemented cryptosystem is that even if there is a dude sitting outside my house, he's not getting a single bit of my data. This is just as true for government secrets as it is sending a recipe to my mother. This service is broken, as all such services are. Bad crypto is never, ever, ever excusable.
- uh_oh 13y ago
  No, he can't. Not without a valid SSL certificate for cryptonote.org. Sure, there are problems with CAs, but it would nevertheless be very difficult to obtain such a certificate.
  - jlgreco 13y ago
    Or (in enough cases to be a valid concern), not without using sslstrip. Which is trivial.
    - uh_oh 13y ago
      If you are the recipient of the link, SSL can't be stripped. Even if you are an author, assuming you have visited the site over SSL at least once, then it can't be stripped on future visits since the site seems to use HSTS.
      - jlgreco 13y ago
        It is trivial to strip links being sent to a user over unsecured channels. There are many things that can mitigate an sslstrip style attack, but coverage from those things is patchy.
tlrobinson 13y ago
Do you believe there is zero value to client-side JavaScript crypto? There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter. EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course). EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.
- daeken 13y ago
  Client-side crypto in JS has value if and only if the following conditions are all met: 1) The application receives no HTML, CSS, Javascript, or code interpreted by plugins from a server in the same context (e.g. not an iframe) as the crypto code. 2) All assets that are run in the context of the crypto code are fixed and signed. No unsigned javascript code (generated at runtime, passed from a server or input to the app, whatever) is permitted to run in any way in that context. 3) The code as signed is completely transparent. It must be possible to audit the code as it would be run, and be able to 'quarantine' updates. Without all of these things being met, client-side crypto in the browser is completely untrustable. These conditions have never been met.

by daeken 13y ago

alainmeier 13y ago

Thanks, and that is absolutely true. That's why it's open source: I want people to host their own version if they don't trust me https://github.com/alainmeier/cryptonote https://github.com/alainmeier/cryptonote

daeken 13y ago
But if you need to trust the server (and you do), then the client-side encryption is 100% pointless. You might as well encrypt on the server with safe, sane, battle-hardened code. At the end of the day, XSS, rogue hosts, etc can own this even if the person "running the show" doesn't want it to happen. Edit: I note that you now link to nadim's response to http://www.matasano.com/articles/javascript-cryptography&#x2F http://www.matasano.com/articles/javascript-cryptography&#x2...; -- you reaaaaally should consider linking to the original, or perhaps to https://news.ycombinator.com/item?id=5768837 https://news.ycombinator.com/item?id=5768837 wherein that article is torn to shreds. JS cryptography is very, very dangerous.

alainmeier 13y ago

Hm, yes, added a warning message, good idea. As for your other thoughts, I completely agree. It's a work-in-progress and I figured the best way to figure out what's wrong is to learn from others. Edit: Also added a link to that discussion next to Nadim's post.

daeken 13y ago
Awesome, glad to hear it!

rmrfrmrf 13y ago

If you're that paranoid, you shouldn't be using a hosted service at all. There could be a guy right outside your house intercepting your cable line and filtering all traffic to and from cryptonote.org and routing it to his own instance of the app. That doesn't mean that cryptonote is responsible for that happening.

daeken 13y ago
This is everything that is wrong with cryptography and privacy. Simply put, if your data is important enough to use cryptography on it, why would you want to use crypto that is broken by design? The whole point of a well-designed, well-implemented cryptosystem is that even if there is a dude sitting outside my house, he's not getting a single bit of my data. This is just as true for government secrets as it is sending a recipe to my mother. This service is broken, as all such services are. Bad crypto is never, ever, ever excusable.
uh_oh 13y ago
No, he can't. Not without a valid SSL certificate for cryptonote.org. Sure, there are problems with CAs, but it would nevertheless be very difficult to obtain such a certificate.
- jlgreco 13y ago
  Or (in enough cases to be a valid concern), not without using sslstrip. Which is trivial.
  - uh_oh 13y ago
    If you are the recipient of the link, SSL can't be stripped. Even if you are an author, assuming you have visited the site over SSL at least once, then it can't be stripped on future visits since the site seems to use HSTS.
    - jlgreco 13y ago
      It is trivial to strip links being sent to a user over unsecured channels. There are many things that can mitigate an sslstrip style attack, but coverage from those things is patchy.

tlrobinson 13y ago

Do you believe there is zero value to client-side JavaScript crypto? There's a spectrum between "unencrypted webpage loaded over cafe WiFi" and "locally compiled open-source application". You don't always need the latter. EDIT: Say you're using a web app that encrypts your data on the client. All the executable assets (html, js, css) are static and hosted on a CDN over HTTPS. The app stores your encrypted data to another server. Even if that server is compromised, it's still impossible to access your data without also compromising the CDN (assuming a correct implementation of the crypto and no XSS vulnerabilities, of course). EDIT2: It would be interesting if you could sign a bundle of static assets that the browser could verify. Maybe as part of the HTML5 app cache. Like a lightweight version of a Chrome app. Add on a restrictive Content Security Policy and it sounds pretty good to me.

daeken 13y ago
Client-side crypto in JS has value if and only if the following conditions are all met: 1) The application receives no HTML, CSS, Javascript, or code interpreted by plugins from a server in the same context (e.g. not an iframe) as the crypto code. 2) All assets that are run in the context of the crypto code are fixed and signed. No unsigned javascript code (generated at runtime, passed from a server or input to the app, whatever) is permitted to run in any way in that context. 3) The code as signed is completely transparent. It must be possible to audit the code as it would be run, and be able to 'quarantine' updates. Without all of these things being met, client-side crypto in the browser is completely untrustable. These conditions have never been met.