4 ms·

If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing a

by mpowers 13y ago

If normal people are going to use it, it has to run in a browser, hence JS. There are working open source crypto libs in JS today, and kind of the nice thing about them is that they're not compiled, so (if unobfuscated) you can literally just inspect the source. That said, we plan to generate keys like bitcoin does, so there if you have a bitcoin library in your language of choice, that part is done. The server code will probably be less useful because there are so many choices, everyone's got their own preferences, and the server is pretty dumb compared to the client. Our leaning is to go with apache tomcat mainly because it's apache and it's widely deployed and, not least, it's what we use.

tptacek 13y ago
No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it, so any inspection they did yesterday will help them not-at-all today * Browser Javascript code is influenced from all sorts of places across the DOM, meaning that you need element- by- element, attribute- by- attribute inspection of the entire page context (and this is before we get into things like caching) to have any clue what a piece of JS code might be doing * The browser itself offers you no mechanism to hash and verify the whole runtime, so there's no way to lock in a specific inspected cryptosystem; even if you have the SHA2 hashes for your crypto .js, you won't have it for every point in the DOM that can override methods in that code Leaning on browser javascript for cryptography is a bad idea that, I think, shows a fundamental disrespect for the security needs of actual real people who will be fooled into relying on it. I strongly advise you to go in some different direction.
- pyre 13y ago
  Shrinking that to a sound-bite: JS crypto is the NSA's wet dream.
- mpowers 13y ago
  If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to let you do so. Let me be clear that JS is not required; it's just how we're making our reference client because we don't believe most people are going to download a custom client. You can write a working client with bash+openSSL+curl if you want. The whole thing is simply signed text snippets over http.
  - tptacek 13y ago
    I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea? Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.
    - mpowers 13y ago
      Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation. Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised. JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.
  - timtadh 13y ago
    > If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an externally loaded resource embedded on the page that resource may modify the execution of your crypto. There are also CSFR, XSS and other JS vulnerabilities to account for. Javascript is a hopelessly bad place to do crypto. Consider doing an signed browser extension that does this on the desktop and native apps on the phone. I would also suggest a native app on the desktop as well. People seem to really like them for twitter.
- silentOpen 13y ago
  While I agree with your general point, there has been some recent work < http://www.defensivejs.com/ http://www.defensivejs.com/ > on isolation of javascript from the rest of the DOM/session. What's your take on this kind of static analysis? Also, if a given, well-known resource could be pinned to a specific hash and third-parties could easily certify that specific hash, would that ameliorate the primary concerns with JS cryptosystems? Thanks for your time.

by mpowers 13y ago

tptacek 13y ago

No, you can't. It's a pervasive and harmful meme that JS crypto code is easy to inspect. But it's not: * If 100 different users are served the code, it's easy to pick 1 unsophisticated user out and serve them something different. * Even if your users are sophisticated, they effectively have to install the code every time they use it, so any inspection they did yesterday will help them not-at-all today * Browser Javascript code is influenced from all sorts of places across the DOM, meaning that you need element- by- element, attribute- by- attribute inspection of the entire page context (and this is before we get into things like caching) to have any clue what a piece of JS code might be doing * The browser itself offers you no mechanism to hash and verify the whole runtime, so there's no way to lock in a specific inspected cryptosystem; even if you have the SHA2 hashes for your crypto .js, you won't have it for every point in the DOM that can override methods in that code Leaning on browser javascript for cryptography is a bad idea that, I think, shows a fundamental disrespect for the security needs of actual real people who will be fooled into relying on it. I strongly advise you to go in some different direction.

pyre 13y ago
Shrinking that to a sound-bite: JS crypto is the NSA's wet dream.
mpowers 13y ago
If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to let you do so. Let me be clear that JS is not required; it's just how we're making our reference client because we don't believe most people are going to download a custom client. You can write a working client with bash+openSSL+curl if you want. The whole thing is simply signed text snippets over http.
- tptacek 13y ago
  I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea? Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.
  - mpowers 13y ago
    Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation. Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised. JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.
- timtadh 13y ago
  > If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an externally loaded resource embedded on the page that resource may modify the execution of your crypto. There are also CSFR, XSS and other JS vulnerabilities to account for. Javascript is a hopelessly bad place to do crypto. Consider doing an signed browser extension that does this on the desktop and native apps on the phone. I would also suggest a native app on the desktop as well. People seem to really like them for twitter.
silentOpen 13y ago
While I agree with your general point, there has been some recent work < http://www.defensivejs.com/ http://www.defensivejs.com/ > on isolation of javascript from the rest of the DOM/session. What's your take on this kind of static analysis? Also, if a given, well-known resource could be pinned to a specific hash and third-parties could easily certify that specific hash, would that ameliorate the primary concerns with JS cryptosystems? Thanks for your time.