11–20 of 45 posts
I don't now how secure this is, but the look&feel of the site is awesome. If you happen to fail in this project, I encourage you to try another one, since you clearly have talent to make really cool web apps.
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. I…
Sorry about the confusion; should have some details up on the site soon! 1 and 2) See 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 i…
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&... 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.
Earlier quoted context omitted.
Sorry about the confusion; should have some details up on the site soon! 1 and 2) See 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 i…
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…
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-migh...
Earlier quoted context omitted.
Sorry about the confusion; should have some details up on the site soon! 1 and 2) See 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 i…
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…
On Cyph: Really dig the look and feel of the app, gorgeous!
[0]: https://keybase.io/warp/warp_1.0.6_SHA256_e68d4587b0e2ec34a7...
I would like to share the link on an iPad. But I guess you were too smart. When I tap on the link to select and copy it, some JS code autoselects the whole link. This is a nice idea and should save me some work. But the copy mode on the ipad breaks. So I cannot copy the link and share it.
Chrome and Android have definitely gotten the most attention so far, though this is the first I'd heard of iOS having issues with that. I had run into a similar issue on Windows Phone (and successfully fixed it), but I'll have to revisit iOS.
As a temporary workaround, does it work when you try a second time? On mobile it should stop trying to grab the link for you after the first time.
Earlier quoted context omitted.
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…
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 strictl…
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://matasano.com/articles/javascript-cryptography/
[0] https://www.schneier.com/blog/archives/2012/10/when_will_we_...
Earlier quoted context omitted.
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 strictl…
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 thes…
First off, that Matasano article was written before the Web Crypto API and is out of date.
Second, Tony's article does make a good point... can you trust that the web site is going to be serving up code that won't spy on you?
Well, can you trust that ANY code on any platform won't spy on you?
People offer that Javascript doesn't have code-signing. Well, that's fucking bullshit. All that needs to happen is someone needs to just, sign all the checksums of the code served to the browser and publish it somewhere. You can then have a third-party site verify that the code is still what it says it is.
Personally, I use this pattern internally. I run my server-side APIs on a different host than my static front-end code. My server-side API then checksums the front-end code and makes sure it is legit before proceeding in certain situations.
Your arguments are weak and out of date.
Earlier quoted context omitted.
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 strictl…
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 thes…
Or would you prefer to parrot the same tired old arguments that pop up on the HN comments every time the concepts "web browser" and "cryptography" are used together?
Earlier quoted context omitted.
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…
Totally novice to security here, but curious to the answer. What if they keep cyph as it is with a warning that this is in browser javascript insecure. They can demo the functionality, then if people want to continue using it (more securely?) they provide a chrome extension to be installed which is sandboxed and maybe also the client-side code is published/signed with (for example) keybase by the developers for addit…
This is our first step, but we have a lot more interesting things in the pipeline in terms of security features.