5 ms·

Yeah... this is a really dangerous and fundamentally flawed idea. Anyone with a basic grasp of cryptography will realize how obviously broken this is: 1. It us

Yeah... this is a really dangerous and fundamentally flawed idea. Anyone with a basic grasp of cryptography will realize how obviously broken this is: 1. It uses JS encryption, which is essentially useless as you could modify it any time to intercept the messages. 2. You claim to be using 'OTR' but there is no key verification, which means it is trivial to intercept. Therefore there is no point at all to using OTR. In addition the point of OTR is to prevent server operators from intercepting communications, which you are still able to do. 3. You've rolled your own crypto library, which hasn't been audited and isn't even known to work correctly or interoperate (i.e: with XMPP OTR clients) with verified implementations. 4. You're using cloudflare which means cloudflare also holds a copy of your TLS key, which means they could also intercept the messages. If you get hacked, if your TLS key gets broken or if one of your employees wakes up on the wrong side of the bed, it's game over. In a nutshell, this is marginally more secure than logging into facebook or gmail over HTTPS and sending each other. In fact in some aspects it's probably less secure because Facebook or Google have strong security teams to monitor intrusions into their servers.

buu700 12y ago
Sorry about the confusion; should have some details up on the site soon! 1 and 2) See https://news.ycombinator.com/item?id=8660233 https://news.ycombinator.com/item?id=8660233 — acknowledged that it's not perfect or 100% trustless yet, but we have some ideas to address that in the future, and for now it's still better than nothing (which is important in cases where you'd have otherwise used nothing). 3) We haven't rolled our own crypto. We're using the JS OTR implementation recommended by cypherpunks.ca (which hasn't been formally audited as far as I know, but is understood to be pretty good). 4) Not using CloudFlare for SSL or CDN, only for DNS management. Our CA is DigiCert (same CA as Facebook and GitHub) and we're running on Google App Engine; it'd be a pretty big deal if either one of those were hacked.
- upperechelon 12y ago
  1. This is not about being perfect, this is about being trustworthy or secure. Right now this is very dangerous to be promoting as even remotely private, as you claim on both your website and twitter. This is no more secure than chatting over facebook. There is no 'clever solution' to get around crypto in the browser, it's always bad. 2. There is absolutely no point to using end-to-end crypto in this setup because it can all be intercepted. Not to mention there is no key verification, so even if you're JS wasn't interceptable it's still trivial to intercept messages. It's a red herring at best and at worst deceptive . 3. I stand corrected, although JS (regardless of whether it's in the browser or not) is usually considered terrible for crypto implementations because of it's math bugs. 4. You might want to check yourself, https://www.ssllabs.com/ssltest/analyze.html?d=www.cyph.com&s=104.28.19.46 https://www.ssllabs.com/ssltest/analyze.html?d=www.cyph.com&... you're pointed to cloudflare's SNI server. I think what you fail to understand is you're relying entirely on TLS for all of your security, which means a LOT of different people are able to read these messages. It's not just your CA that could be compromised to hack you, its ANY CA. So for example the chinese government decides they want to read everyone's messages, all they need to do is publish a cert with your domain. Or any of your staff. Or anyone at cloudflare. Or anyone with access to your server. Or access to your home computers which have login credentials.
  - buu700 12y ago
    4) We're using CloudFlare to redirect our naked domain to www.cyph.com. Re: the rest, assuming the user trusts that we haven't served up malicious code (which, again, I acknowledge isn't completely trustless for now), I disagree that JS crypto is bad/useless. It definitely was bad/useless at one point in time, but with the introduction of the Web Crypto API I haven't seen a convincing argument that it's still strictly inferior to C/C++ crypto. (And, to be clear, Cyph will refuse to run in a browser without Web Crypto API support, e.g. any version of IE before 11.) I'd argue that a safe language like JavaScript running in as well-vetted a sandbox as in modern browsers has a lot of pretty favourable security properties (entire classes of exploits are impossible here, as opposed to in Pidgin/OTR whose implementation is known to be less than ideal for security[1]). 1: http://motherboard.vice.com/en_ca/read/secure-messaging-might-not-be-so-secure-otr-libpurple http://motherboard.vice.com/en_ca/read/secure-messaging-migh...
    - upperechelon 12y ago
      4) So they can redirect all users to a non-HTTPS site. That's interesting. What youre saying is ridiculous, it's nothing to do with "completely" trustless, you're not trustworthy at all. The "we promise we wont serve malicious code" is the same securi Basically your users have to trust: -You -Your staff -Cloudflare -Google -Any computer used to design, build or login to your web app -Anyone with access to any of these computers -Every single CA in existence (including the US and Chinese government) -Anyone with resources to spoof a CA SHA-1 signature (anyone with ~$700,000 [0]) -The authors of the JS OTR library and any other code you use Do you see the problem here? There are literally millions of people in your trust chain. Libpurple sucks, but browsers are the #1 target for exploit writers, not to mention the HUGE attack surface they pose. There are just so many angles of attack for your service. Anything hosted on a shared server is not secure. The word cloud and security should not be in the same sentence. No offense, but you guys really do not seem like cryptography experts and there are so many pitfalls here that I would not recommend trying to promote this until you completely re-design everything. As far as WebCrypto.. I'm just going to leave this here: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ [0] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...

buu700 12y ago

Sorry about the confusion; should have some details up on the site soon! 1 and 2) See https://news.ycombinator.com/item?id=8660233 https://news.ycombinator.com/item?id=8660233 — acknowledged that it's not perfect or 100% trustless yet, but we have some ideas to address that in the future, and for now it's still better than nothing (which is important in cases where you'd have otherwise used nothing). 3) We haven't rolled our own crypto. We're using the JS OTR implementation recommended by cypherpunks.ca (which hasn't been formally audited as far as I know, but is understood to be pretty good). 4) Not using CloudFlare for SSL or CDN, only for DNS management. Our CA is DigiCert (same CA as Facebook and GitHub) and we're running on Google App Engine; it'd be a pretty big deal if either one of those were hacked.

upperechelon 12y ago
1. This is not about being perfect, this is about being trustworthy or secure. Right now this is very dangerous to be promoting as even remotely private, as you claim on both your website and twitter. This is no more secure than chatting over facebook. There is no 'clever solution' to get around crypto in the browser, it's always bad. 2. There is absolutely no point to using end-to-end crypto in this setup because it can all be intercepted. Not to mention there is no key verification, so even if you're JS wasn't interceptable it's still trivial to intercept messages. It's a red herring at best and at worst deceptive . 3. I stand corrected, although JS (regardless of whether it's in the browser or not) is usually considered terrible for crypto implementations because of it's math bugs. 4. You might want to check yourself, https://www.ssllabs.com/ssltest/analyze.html?d=www.cyph.com&s=104.28.19.46 https://www.ssllabs.com/ssltest/analyze.html?d=www.cyph.com&... you're pointed to cloudflare's SNI server. I think what you fail to understand is you're relying entirely on TLS for all of your security, which means a LOT of different people are able to read these messages. It's not just your CA that could be compromised to hack you, its ANY CA. So for example the chinese government decides they want to read everyone's messages, all they need to do is publish a cert with your domain. Or any of your staff. Or anyone at cloudflare. Or anyone with access to your server. Or access to your home computers which have login credentials.
- buu700 12y ago
  4) We're using CloudFlare to redirect our naked domain to www.cyph.com. Re: the rest, assuming the user trusts that we haven't served up malicious code (which, again, I acknowledge isn't completely trustless for now), I disagree that JS crypto is bad/useless. It definitely was bad/useless at one point in time, but with the introduction of the Web Crypto API I haven't seen a convincing argument that it's still strictly inferior to C/C++ crypto. (And, to be clear, Cyph will refuse to run in a browser without Web Crypto API support, e.g. any version of IE before 11.) I'd argue that a safe language like JavaScript running in as well-vetted a sandbox as in modern browsers has a lot of pretty favourable security properties (entire classes of exploits are impossible here, as opposed to in Pidgin/OTR whose implementation is known to be less than ideal for security[1]). 1: http://motherboard.vice.com/en_ca/read/secure-messaging-might-not-be-so-secure-otr-libpurple http://motherboard.vice.com/en_ca/read/secure-messaging-migh...
  - upperechelon 12y ago
    4) So they can redirect all users to a non-HTTPS site. That's interesting. What youre saying is ridiculous, it's nothing to do with "completely" trustless, you're not trustworthy at all. The "we promise we wont serve malicious code" is the same securi Basically your users have to trust: -You -Your staff -Cloudflare -Google -Any computer used to design, build or login to your web app -Anyone with access to any of these computers -Every single CA in existence (including the US and Chinese government) -Anyone with resources to spoof a CA SHA-1 signature (anyone with ~$700,000 [0]) -The authors of the JS OTR library and any other code you use Do you see the problem here? There are literally millions of people in your trust chain. Libpurple sucks, but browsers are the #1 target for exploit writers, not to mention the HUGE attack surface they pose. There are just so many angles of attack for your service. Anything hosted on a shared server is not secure. The word cloud and security should not be in the same sentence. No offense, but you guys really do not seem like cryptography experts and there are so many pitfalls here that I would not recommend trying to promote this until you completely re-design everything. As far as WebCrypto.. I'm just going to leave this here: http://tonyarcieri.com/whats-wrong-with-webcrypto http://tonyarcieri.com/whats-wrong-with-webcrypto http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ [0] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html https://www.schneier.com/blog/archives/2012/10/when_will_we_...