https://www.cyph.com/privacypolicy Your second to last bullet point is not really possible.
Show HN: Cyph – Encrypted chat in 30 seconds
21–30 of 45 posts
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#22Could the designers indicate what would be the class of entities that this is supposed to protect my chats from ? the guy on the same wifi ? isp ? routers on the way ? govt entities ?
In a number of threads it was claimed that this is better than nothing or better than https, could you (all) elaborate on why that would be so. If I am just locking one door of my car leaving the rest open, I sure would like to know and at the moment this is what it sounds like but I am quite the ignoramus so please correct my misapprehensions.
EDIT
@buu700 Thanks for replying.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#23https://www.cyph.com/privacypolicy Your second to last bullet point is not really possible.
Ignoring the semantics of the phrasing (that's just a temporary placeholder), the intent is to say that we won't ever willfully send a decrypted copy of our users' encrypted data to our servers.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#24Earlier quoted context omitted.
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…
Explain to me the trust chain of a crypto messaging app that you DO think is safe and secure. Seriously, pick one, let's talk about it. Let's compare and contrast. 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?
Thinking about the answer to this hurts my brain. Ultimately, with the amount of money and resources available to the "bad guys", I can't imagine something as truly uncrackable.
But I am just a lowely infrastructure guy that builds VPNs, lots of smart folks out there :)
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#25Could the designers indicate what would be the class of entities that this is supposed to protect my chats from ? the guy on the same wifi ? isp ? routers on the way ? govt entities ? In a number of threads it was claimed that this is better than nothing or better than https, could you (all) elaborate on why that would be so. If I am just locking one door of my car leaving the rest open, I sure would like to know and…
Sure, we can clarify that on the site. (Thanks for the feedback! It's become pretty clear that our supporting content/documentation needs a lot of work.)
The intent isn't to protect from certain classes of entities, so much as to absolutely protect with a certain degree of confidence. That is to say, Cyph is a convenient tool that probably keeps your secrets from, say, governments; but if you're in a life and death situation you should consider carefully whether you have better options.
That being said, now that I think about it, there isn't an obviously better alternative in such a circumstance that I could recommend. Pidgin OTR is probably what I would have chosen a few years ago, and for now it's maybe still what I'd pick, but based on what I've been seeing in the OTR mailing lists and the Vice article I linked in another comment, it's really not a great option. TextSecure might be a good alternative if using it on a phone isn't too big a problem. There's always tried and true PGP, though where applicable the OTR protocol has much more interesting security properties IMO.
tl;dr: There's really no silver bullet, but Cyph has as good a chance as just about any alternative of protecting your secrets. I wouldn't stake my life on it quite yet, but I wouldn't stake my life on any existing alternative either. If things go as planned and we execute well on the next steps, it shouldn't be too long before I'd consider Cyph strictly better than any alternative.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#26Earlier quoted context omitted.
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…
Explain to me the trust chain of a crypto messaging app that you DO think is safe and secure. Seriously, pick one, let's talk about it. Let's compare and contrast. 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?
Here, I'll speed it up for you with this conclusion:
Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is.
Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user.
Web site where signed checksums are published? Can't be trusted. It could have been hacked or altered.
Checksum embedded in executable which checks itself at run time? Can't be done.
Trust is the issue. Trust NEVER goes away. The only way to know for sure is if you compile all your own code. But wait, remember Ken Thompson on Trusting Trust? You had better be building your own compilers as well...
So basically you're saying that no one but computer experts who build their entire toolchain from scratch should be using any sort of application that uses cryptography.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#27Earlier quoted context omitted.
Explain to me the trust chain of a crypto messaging app that you DO think is safe and secure. Seriously, pick one, let's talk about it. Let's compare and contrast. 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?
Here, I'll speed it up for you with this conclusion: Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is. Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user. Web site where signed checksums are published…
Those problems are quite serious. A positive step is that they've been increasingly recognized as serious by people who develop and publish software, so there are significant transparency efforts underway now to try to make it possible to meaningfully tell where software came from, whether it corresponds to published code, and whether it's the same thing everybody else is using.
(Along with Mike Perry from the Tor Project, I gave a talk about some of these issues at Mozilla recently, which was pretty well-received. Tor has been very interested in making sure that compromises of their infrastructure won't compromise the software their users get, and that the developers can't be coerced into giving users backdoored versions; see Perry's "Deterministic Builds Part One: Cyberwar and Global Compromise", for example.)
To look at this from another angle, all of these issues are terrible gaps in software security, and terribly exciting opportunities for people to add backdoors (maybe more likely bugdoors), but now we have some tools and ideas that can start to address them!
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#28Earlier quoted context omitted.
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…
Oh, so an argument to authority? 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 th…
I tried to submit an "Ask HN" item (motivated by this debate today) about what kinds of tools and best practices there are for doing this, but it didn't get voted onto the front page.
I'm concerned about the "third-party site verify that the code is still what it says it is" if an important part of the threat model is that an attack would be deployed against only some users, not all. How can the third-party site tell if the site is attacking an individual user? How can the individual user compare the version of the web app they received with the version that the third-party server thinks is appropriate or current?
I don't mean to dismiss this goal, because I really want infrastructure like this to work and become ubiquitous, I just think it might require a slightly more elaborate architecture with the addition of some kind of client-side component, if you're including the original developer in your threat model, and not just someone compromising the servers that host someone's copy of jQuery and giving everyone a backdoored copy.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#29Earlier quoted context omitted.
Oh, so an argument to authority? 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 th…
I tried to submit an "Ask HN" item (motivated by this debate today) about what kinds of tools and best practices there are for doing this, but it didn't get voted onto the front page. I'm concerned about the "third-party site verify that the code is still what it says it is" if an important part of the threat model is that an attack would be deployed against only some users, not all. How can the third-party site tell…
Let's talk about targeting specific users in the scenario where you've kept your server-side API separate from your static front-end code.
The compromised front-end code server would need to know that specific users host and client in order to target a specific user. Users are logging in to the server-side API. They all get the same front-end code.
If a third party site tested from a variety of hosts using a variety of spoofed client information it would be very probable for it to detect code that targeted broader user fingerprints.
You're right in that this wouldn't protect against targeted individuals. But neither does an executive order from the state.
Web applications are an orchestration of two separate pieces of software that can work together using multi-factor authorization and signature schemes to offer a substantial amount of enhanced security when client-side crypto is properly utilized.
Re: Show HN: Cyph – Encrypted chat in 30 seconds
#30Earlier quoted context omitted.
Here, I'll speed it up for you with this conclusion: Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is. Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user. Web site where signed checksums are published…
Those problems are quite serious. A positive step is that they've been increasingly recognized as serious by people who develop and publish software, so there are significant transparency efforts underway now to try to make it possible to meaningfully tell where software came from, whether it corresponds to published code, and whether it's the same thing everybody else is using. (Along with Mike Perry from the Tor Pr…
Great!
Can we now stop pretending that browser crypto is the only thing is susceptible to these issues?