4 ms·

Am I understanding correctly that you consider your adversary to be the National Security Agency, the world's best funded, best equipped, best staffed SIGINT ag

by buu700 11y ago

Am I understanding correctly that you consider your adversary to be the National Security Agency, the world's best funded, best equipped, best staffed SIGINT agency, and that you think they're limited to passive observation? No, you aren't; the example was to illustrate an entirely different point. Again: I just think this is a bad idea. I'm sure you're great people, but cryptographic security is hard enough for native apps, without trying to deploy it in the jungle gym of some random browser runtime. Do you have a specific criticism, or is your argument more of a general point that solving multiple hard problems is more difficult to do correctly? If that is what you're getting at, it seems like it would be effectively addressed by frequent audits of the Cyph source code.

tptacek 11y ago
There are very specific concerns I have about implementing secure cryptography in a browser runtime. I wrote an article about this a while back. I don't love that article and never did, but one complaint I've heard about it is that it's "dated". In fact: I think the last few years have made it harder to securely deploy crypto in a browser. So one short answer is, for a bunch of fiddly reasons, I think you're building one of next year's Black Hat Briefings talks. But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!". It's great that you paid for an audit, but audits aren't magic feathers. If you got audited again by a strong team, they'd find other things you missed. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! Crypto is hard even on the "easy" setting. You've got the difficulty setting dialed all the way to "nightmare". Dial it back down.
- buu700 11y ago
  There are very specific concerns I have about implementing secure cryptography in a browser runtime. ... What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript? I'm aware that asm.js isn't literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is vastly different from a project like Cryptocat. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! It was an accident, in pre-production code. (And hardly "nightmare"-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn't obviously exploitable.) That was also the only bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not. The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod. This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we'd been using if Castle turned out to be unfit for production. --- 1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated/no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.
- cyphar 11y ago
  > But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!". I agree with you about web crypto, but I disagree with this point. A point that Roger Dingledine (of Tor fame) made a few years ago was that people who are going to say something which their government doesn't want them to say are going to say it anyway. If they can't communicate using the internet, they are willing to make protests in the streets, to shout and scream to try to improve their world. The job of people making cryptosystems to try to keep such activists safe is to minimise risk and do the best they can. You shouldn't think that you're responsible for what happens to those people, you're doing the best you can for them. But at the end of the day, they are willing to die for their goals and it is disrespectful to ignore that fact. But yes, I agree that the service in question probably needs much more work. And it should probably say "this is still Alpha".

by buu700 11y ago

tptacek 11y ago

There are very specific concerns I have about implementing secure cryptography in a browser runtime. I wrote an article about this a while back. I don't love that article and never did, but one complaint I've heard about it is that it's "dated". In fact: I think the last few years have made it harder to securely deploy crypto in a browser. So one short answer is, for a bunch of fiddly reasons, I think you're building one of next year's Black Hat Briefings talks. But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!". It's great that you paid for an audit, but audits aren't magic feathers. If you got audited again by a strong team, they'd find other things you missed. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! Crypto is hard even on the "easy" setting. You've got the difficulty setting dialed all the way to "nightmare". Dial it back down.

buu700 11y ago
There are very specific concerns I have about implementing secure cryptography in a browser runtime. ... What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code via TypeScript? I'm aware that asm.js isn't literally native code, but we and, (without putting words into their mouths) I believe, the Cure53 team felt that these were both very effective mitigations to the risks you point out. Combined with a strong CSP and an entirely Angular-based UI (so no silly mistakes like untrusted user input in jQuery selectors, and to date no known XSS), I would say that Cyph is vastly different from a project like Cryptocat. As it stands, the team that audited you found devastating crypto flaws; for instance, you repeated nonces! It was an accident, in pre-production code. (And hardly "nightmare"-level; it was one nonce reuse that only occurred during the initial handshake, and notably wasn't obviously exploitable.) That was also the only bug found by 5 experts over 12 days in the entire protocol implementation[1], which I would say is more impressive than not. The whole point of that audit was to catch those sorts of silly mistakes before we switched away from OTR in prod. This also has nothing to do with WebSign or the impact the browser has on our attack surface; we could very easily switch back to the asm.js libotr cross-compilation we'd been using if Castle turned out to be unfit for production. --- 1: There were three Castle-related findings, but only one was in the Castle implementation. One was an outdated/no-longer-correct statement in a document and one was a configuration weakness elsewhere in the code.
cyphar 11y ago
> But the broader concern is, in fact, that by offering people a secure messenger, you're accepting some responsibility for securing traffic that can jeopardize lives if you're compromised. You have, I think, a moral responsibility to be as conservative as you possibly can be. When someone gets hurt because this system is flawed --- assuming you ever learn about it --- I think you're going to be surprised by where it happened. People with causes you've never even considered will use this thing in ways that, if you knew about, you'd say "fuck! stop! i like my application but i can't let you bet your life on it!". I agree with you about web crypto, but I disagree with this point. A point that Roger Dingledine (of Tor fame) made a few years ago was that people who are going to say something which their government doesn't want them to say are going to say it anyway. If they can't communicate using the internet, they are willing to make protests in the streets, to shout and scream to try to improve their world. The job of people making cryptosystems to try to keep such activists safe is to minimise risk and do the best they can. You shouldn't think that you're responsible for what happens to those people, you're doing the best you can for them. But at the end of the day, they are willing to die for their goals and it is disrespectful to ignore that fact. But yes, I agree that the service in question probably needs much more work. And it should probably say "this is still Alpha".