Powered by code that you download every time you use it, and that therefore can leak your keys and conversations at any time, just as centralized chat can.
I frankly never trusted Mega in the first place. Their claims were always grandiose and absurd and their business model (back as Megaupload) was always a bit sketchy.
When I want secure chat, I use Signal from WhisperSystems. Yeah it has usability issues, but it's obvious it's hard to do really secure and secret chat.
Nice! For those that don't know, Kim Schmitz / Kimble(now Dotcom), sold out his fellow warez peers to the copyright lawyer Günter Freiherr von Gravenreuth. Like the wild West he was supposedly paid per head.
Not mentioned in the article is his involvement in the AT&T calling card fraud conspiracy (estimated losses $20 million) in the early '90's. It is that case that put him on the US Secret Service's radar and he's been on it ever since.
yepp indeed. that just made me think ... a lot of things weren't ... such as bribing gov officials when participating in tenders (example Siemens and others learned the hard way). Lot of things seemed to have become illegal in Germany just over the past 20 years. Now they're even trying to curb our creativity when writing software for exhaust emmissions test /s
It sounds reasonable? If anything this highlights the problem with all the new encrypted communications options, even highly technical people can't really know how good it is from a cursory look. Just because it says end to end encryption and uses some nice ciphers it doesn't mean the implementation is not critically flawed.
I use Signal right now (from Moxie Marlinspike/Whisper Systems) and would only really consider alternatives if they were endorsed by other cryptographers I know because I really just don't have a strong enough grasp of how all the machinery interacts.
Not on iOS. It's not Signal's fault that Android permissions are a mess. Google has no interest in providing good privacy to their customers. They only want to appear to provide privacy. In reality, they want to know everything there is to know about everything and everyone. To improve their service, of course...
The requirement of a phone number is strange and disconcerting from a privacy standpoint. It is a red flag for me.
A well-designed encrypted chat-protocol should work on any modern networked computing device, not just smartphones or computing devices linked to a smartphone.
Recent updates also show disconcerting "Joe is on Signal!" messages for everyone in your contacts (who is registered with Signal) regardless of whether or not you've had any contact with them. They've stated that this is not a security issue (I don't recall the specifics) but it was pretty disturbing nonetheless. I'll definitely be paying closer attention and consider switching to an alternative if this trend continues.
I've recommended Signal (then TextSecure) to a number of non-technically savvy friends as a trustworthy app that takes security seriously. Moxie is somewhat unique in this respect, among the sea of proprietary apps put out by larger shops. Upon seeing these "X is on Signal" messages, I had a number of people contacting me with concerns. At least the outward appearance is that Signal is somehow leaking contact data to their servers. Presumably it is also alerting people to the fact that "Joe" is a Signal user, despite no communication with that user having taken place.
I realize that phone numbers are probably hashed before being sent, with only local contact data being displayed, but it has people concerned nonetheless. It starts to err more towards convenience, ease of use, and network building above security.
I think we should push for Axolotl (the cryptosystem used by Signal, which is an improvement on OTR) support in Ricochet and get a Ricochet phone app.
Ricochet uses Tor hidden services to anonymise your social graph, which is something you don't do with Signal (not to mention that Signal does identity key lookups with phone numbers). I'm not sure there's a low-latency way to do VOIP anonymously. The best method I know of is to literally record and send audio files, which have a few seconds of latency.
you can easily enumerate this data anyway, though. Just go through your contact list and try to add people. You could come up with an elaborate system where the other person has to confirm you, but everyone knows that's rubbish and users hate it. Sorry for the late response, I forgot I made this comment.
Yes I'm well aware at the ease in which someone could build a client that would provide such a feature had it not been included. Moxie takes great care not to provide mere illusions of security (or in this case obscurity) such as self-destructing messages or other features of that ilk. I appreciate it, and it's a big part of why I use and recommend projects affiliated with Open Whisper. Still don't believe it was the right decision to blast users with a notification from every Signal user in your contacts. Let Telegram or Whatsapp or some other crap play that game.
While you can't know without looking at the code, my first-pass test is asking how keys are handled and if the code handling those keys is coming from an untrusted source (in this case the server as JS)(for the sake of this discussion I will admit I implicitly trust Debian and the gpg folks).
If there isn't a good answer to key management, or my key is handled by JS, then it's a no-go for me.
If there is a half-way decent answer to key management, I ask what the threat vectors the system was designed for are. If a broad political statement is made, then I walk away.
While it doesn't actually vet the technical merit of the code, I feel it catches a lot of funniness.
Probably the best key handling method is employed by Biocoded app. It uses the same encryption protocol as signal (Axolotl ratchet) and it only stores half of the decryption key locally. The other half is on the server.
The problem with key management is that everyone tries to solve the management problem with a single solution. A single method will always have to make choices about the threat model, which can only truly be known by the user. A single user can even have more than one threat model, depending on what they are doing.
What we need instead is some sort of configurable layer that allows the user to specify how keys should be managed by selecting what they want to trust.
They could use a default delegation to a public trust root (the PKI model, no configuration needed) for most things. Receiving a call from the bank could instead be authenticated with the key they got when they physically walked into the local branch. Chat with their immediate friends who can exchange keys on their phone when they meet up in person is easy, and a web of trust can extend that to a friend-of-a-friend. People understand the concept of vouching for someone, and over time more than one method can be used to cross-check.
Key management shouldn't be "PKI vs web-of-trust vs out-of-band-keybase-style vs manual-key-exchange vs ..."; it should be "all of the above, with the chain-of-trust exposed". Anything else is making assumptions about what the user's current needs.
Is there any information on the guaranties Moxie Marlinspike/Whisper Systems provide on the Apps downloaded from the App-Store?
I get that their source is open and reviewed and trusted but what is this worth when there is no way to tell if users are actually using their version/builds when installed from App-Stores. Same holds true for the necessary servers they maintain.
Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right?
Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with?
The solution is called reproducible builds. I'm aware f-droid is working on these, but most of the work is currently happening more in the Linux distribution space (Debian is leading that cause). I hope in the future we will be able to say "if it doesn't have a reproducible build process it's not to be considered trustworthy".
(Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
Aren't builds typically reproducible? What makes builds non-reproducible? I know the Debian folks are very enthusiastic about reproducible builds, and for a huge system I can see that things can vary -- but what tends to be varying in the case of individual components? If I build a library from the same revision of a source tree I expect the exact bits to come out, if the same compiler version was used? When does it not?
Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library?
Googling reproducible builds mainly gets you Debian info, not a general description of the issue
A build is not reproducible where it incorporates both open and closed code. A company may "open source" some important stuff (encryption algorithms) but keep enough code closed that the final build cannot be duplicated from the "open" code. It is therefore difficult to judge whether the open code has actually been adopted properly, or whether any closed code hasn't created new bugs.
Reproducible builds are on our very-near-future roadmap at Cyph, which will be important to mitigate a hypothetical scenario in which we somehow lose our minds and deploy code that differs from the GitHub repo.
We control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.
You can always compile the programs yourself - you will have to pay for a dev account for iPhone (I think) but Android is free and you can sideload the new app you trust.
It's great that there is such a strong interest in secure communication, but all of the solutions that keep getting placed in the limelight in recent years are either centralised or exclusively available for use with a smartphone (because of the phone number requirement), often both!
I'm sure that these solutions are a lot more secure than completely unprotected alternatives, but am I wrong in assuming that if you want secure and private communications, the following principles must be met at the least?
* The protocol used must be open, standardized and implementable by others
* Widely endorsed by cryptography experts
* An implementation must be available and developed as free and open source software
* End-to-end encryption is used for the contents of the conversations, private keys do not leave the user's computing device
* The protocol must not have any technological barriers that prevent an implementation from working on any modern operating system (i.e., a phone number is not required)
* The protocol must allow for a complete communications network (clients and servers) to be implemented without the need for centralised third-party services
(The last point probably implies federation.)
For e-mail, OpenPGP meets these requirements. For chat, XMPP has Off-The-Record messaging.
Some of the above points are hostile towards any party that creates secure communications tools with the intent of growing a large user base for economic purposes. Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principles — for anyone betting on creating the next WhatsApp in one of the mobile walled gardens embracing the whole list means risking losing your potential advertising eyeballs to alternatives.
Of course, there is also the matter of infrastructure. A lot of people expect to be able to use these tools for free, but that implies that someone is paying for the hosting of (relay) servers.
> Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principals
OpenPGP is impossible for most email users to get working correctly.
Remember that most people don't even know the difference between CC and BCC.
Difficult perhaps, certainly not impossible, and quite feasible if someone helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for everyone; only for those who understand how to use the technology properly.
I mention OpenPGP and XMPP OTR because they are examples of open standards that do fulfil the principles outlined above. That is, to illustrate that it is certainly not impossible or infeasible to create such a technology. What is missing is a technology that does that, and allows anyone (regardless of technological prowess) to use them safely. It is a tough problem though.
From a UX perspective, can we do better? I'll base both off my personal experience - Kmail and KDE Telepathy - since those are my email and IM client.
In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity -> Modify -> Cryptography, change my signing and encryption keys (and it supports PGP or MIME) and then, since I don't already have keys, need to open Kleopatra, the KDE GPG client.
Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file -> new certificate to make one. Its a wizard, so you go step by step, setting up a password for the cert along the way. You also make a revoke cert you save somewhere.
Once you made the key, you need to export it to the server. And you probably want to make a signing and encryption key, since if you got this far you are already a super techy nerd and that is what makes my point right there.
If you want normal people to be able to use gpg in kmail, there needs to be a wizard just like the "add account wizard" called "Setup GPG" that searches for keys that match your email address first in case you already have them and if there are none generates you new ones and just asks you for the password. It handles the propagation and importing of keys itself because thats not something a user should be dealing with unless they need to.
And even that is unlikely to happen - you want the GPG setup to really be a part of the first-start of Kmail process. Like the first time you open the program and get the "add account" button you should also get "setup security".
But even if you can get people making keys, the UX sucks because it makes them enter a password every time you send an email. You should be able to do what kwallet recently did, and bind the unlock key to your GPG keys to your user session so that when you enter the desktop via SDDM it unlocks your GPG keys just like it unlocks your wallet. Then people can use secure email whenever they want without any bullshit.
There are even more UX nightmares - getting your keys across different computers, easily revoking them if they get compromised, even knowing what that means.
By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use OTR" button and if your chat partner does the same it automagically generates and shares the keys, no user interaction required. The only downside is that you don't get local logging of your OTR conversations - that should definitely be an option, maybe even encrypt them with your kwallet keys! Eh, eh?
But these kind of UX nightmares keep secure communications from being a thing. Mumble is literally the best security solution I have, because I can get a letsencrypt cert, run my own server, put on a password, and anyone chatting on it has perfect security in voice and text - the whole thing is encrypted, I can do my own trust network based off my x509 cert, and it even supports pinned users so nobody can impersonate anyone else.
But I say that its the best because for anyone I invite, they literally just need to enter the password I give them to my server. Sure, its problematic to give them the password if you don't have a secure communication link beforehand, but I guess thats what OTR is for! Oh drat...
I think before you even tackle the ui issue there's a general knowledge hurdle you have to cross. Most people are unable to reason about or manipulate uis around keys because they fail to understand the purpose and basic mechanism of them. I spent roughly 5 hours explaining the general concepts behind public key cryptography to my girlfriend and this was only possible after making a compelling argument that everyone should use encryption even if they have "nothing to hide". She works as a technical writer, I can only imagine the barriers to instilling these concepts in someone with less technical vocabulary.
This can't be overstated. Even if we got the general public to sort of understand PGP and PKI there is going to be a significant number of users that don't understand the difference between a password and a password protected key. The expectation is going to be that when they move to a new computer that their "password still works" and are going to be extremely angry when it doesn't.
Thats why you cannot expect them to understan PGP and PKI. You want a sane default that can secure 99% of people and expose the guts to the last 1% through options menus.
The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and encryption key based off your password, backs it up on their server (remember, its password protected, they cannot access it despite backing it up) and then whenever you sign in on other device your keys are downloaded and just work.
This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
And I worry even that is too complicated for my grandmother to be willing to put up with to stop the NSA from reading her emails.
> The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and encryption key based off your password, backs it up on their server (remember, its password protected, they cannot access it despite backing it up) and then whenever you sign in on other device your keys are downloaded and just work.
> This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
Or you could carry your keys around with you on a physical smart device that communicates over usb or nfc. This ux already seems to work well in corporate environments, it's just a matter of convincing consumers it's worthwhile and vendors to bake support into their products.
If the FIDO U2F standard takes off, we may just see this happen. U2F keys do not include the functionality to hold OpenPGP keys, but they could help in having people understand the notion of a keychain for security.
I 100% with you that UX is the most important problem that is not solved with PGP, and as long as nobody will do something we'll never be able to use crypto. I also believe that if your crypto doesn't solve something that PGP doesn't already solve, then you'd better spend your time on bettering UX instead.
However Mumble is not a valid comparison, because Mumble is not End-to-End encrypted. The security of Mumble amounts to an encrypted connection to the server, protected by a password; from this POV Mumble is no more secure than Facebook or Hacker News.
It is end to end encrypted when you are one of the participants and you own the server. Thats what I mean by its the best secure communications solution I have - I can sholder the work of getting a valid cert, but once its setup as long as I trust who I'm talking to is who I think I'm talking to, I am sure nobody can evesdrop because its my server. And for the people I care to have private conservations with, downloading / install Mumble on their phone or desktop is their regular patterns of behavior and isn't inconvenient at all compared to insanity like GPG or OTR.
"You're browsing without Javascript! If you have no idea what that means, you should ask your technical friend about it. Otherwise - kudos."
No, kudos to you. I could count on one hand the number of times I have been congratulated by one of these capability detection messages for browsing without Javascript.
We will release in next two weeks encrypted end-to-end version of Actor.im that will met this requirements except that is will be reviewed, important part but we will do this in nearest future.
I think a reasonable compromise would be to just insist on some type of federation with other systems. These days that means XMPP federation. Then the option of OTR for privacy and you are good to go. You can provide all the fancy features you want between your clients, but those clients will also have the feature of being able to communicate with people not using your app/program.
Perhaps the combination of federation and OTA can be given an impressive sounding name, a nice logo and a foundation (everything needs a foundation). Then the name/logo can show up on feature lists. People love features...
The "don't roll your own crypto" mantra was created by the NSA to make people afraid to develop and deploy cryptography. See here: http://www.youtube.com/watch?v=fwcl17Q0bpk
Since no one else has explicitly brought this up: https://tonyarcieri.com/whats-wrong-with-webcrypto (also see Matasano's "JavaScript Cryptography Considered Harmful", etc.). There is nothing that a service like this will protect you from that you don't already get while using TLS in just about every insecure/non-E2EE chat service.
If you're looking for actually secure communication that runs as a Web app, my startup Cyph (cyph.com) is the only option that exists. This is because we put in the time to build it correctly; the root page of our application is a permanently pinned (TOFU) bootstrap that validates/executes signed application packages, and the scheme to accomplish this was rigorously vetted in a 12-day audit.
I don't know what you mean by, "permanently pinned (TOFU) bootstrap", but the fact that it "validates/executes signed application packages" doesn't sound like it protects the end user from you sending them a "signed application package" which contains something to steal their keys/messages...
If you could post a link explaining how this tech works, I would be very interested in reading about it...
It doesn't protect users from that yet (neither does Signal or any other alternative), but we are about to implement reproducible builds to help mitigate that by allowing users to independently verify that the deployed production build matches up with our source code on GitHub.
That having been said, my cofounder and I are the only two people with the keys to sign releases (and as long Cyph exists they'll only ever be held by either ourselves or an equally small set of individuals deemed worthy to trust with our lives) — so you shouldn't ever expect that kind of deliberate backdoor, even if I end up in prison for refusing. We're also maintaining a strong focus on OpSec of these keys, e.g. we're about to migrate the release signing off of our (full disk encrypted) personal laptops to a dedicated air gapped environment.
Nice to hear that you say you have nothing up your sleeves. I believe you don't, but if you were an agent for a covert agency you would make the same claims, so they mean nothing.
As for opsec on keys... the only thing making key extraction remotely difficult by a state actor is probably some form of hsm - but recalling the xbox 1 crack, I don't know how well even those stand up in practice. For everything else, I assume you're just a sneak-and-peak warrant and some cameras/listening-devices away from sharing your passphrase.
Don't get me wrong, I think it's great that people are working on secure chat applications. I just think one needs to be very careful making claims that end up on the side of being secure against state actors.
Definitely agreed re: the meaninglessness of my promises; if someone's threat model were to include that degree of trust in a complete stranger, then there would be no point in that person using encryption to begin with.
Also agreed on all other counts; if all else failed, I have no doubt that a state actor could certainly extract our keys through targeted physical surveillance and/or force, which I don't think there's really a good workaround for short of raising our own army to protect a private bunker for air gapped release signing.
What this first iteration of the air gapped environment is meant to accomplish is to simply make it that much harder. Sure, the CIA can still probably break into my home and set up a surveillance camera to steal the encryption passwords of my keys without my noticing, but what they will no longer be able to do is steal them by tampering with my laptop while my head's turned in broad daylight.
As Cyph continues to grow as a company, we expect to have the resources to implement increasingly sophisticated OpSec measures.
Good catch. Mario actually provided a marketable quote via email (signed and all). Although that quote is intended as a one-sentence summary of Mario's report, it's not strictly a quote out of the report as much as it is strictly a quote from Mario. Therefore, the source on the quote might more accurately be attributed as "Mario Heiderich in summarizing the Cure53 pentest report."
The thinking there was that there wasn't a good way to quote any single part of the report without introducing unnecessary and/or fishy ellipses, because although the point of the rest of the conclusion is that it confirms the claim made by Cyph, there wasn't a readily available standalone sentence in there which could go on the front page.
Background: I advised Cyph on AppSec topics on behalf of Mach37 as a mentor, and I helped coordinate the Cure53 pentest. I'm the one who sourced the quote.
Give me a few moments (or days; we'll see) for me to find a good way to publicly and non-repudiably present the exact source of the quote.
I don't think it's a good idea to provide secure messaging services that boot from a web page, under any circumstances.
This stuff has to work. The adversary for secure messaging is world governments. If all you're worried about is criminals, Gchat will do a fine job of protecting you. For a vivid example of what I'm talking about, see the Telegram/Iran fiasco.
It's hard enough building secure messaging in a native application; there are lots of details that are not easy to get right (as Cure53 demonstrated to your team).
Bluntly: I feel that it's irresponsible to add to that portfolio of difficulties the added attack surface of content-controlled Javascript.
The reason people build services like this is that users will prefer them to (more secure) native app alternatives. It's easy to see why. The common response to this observation is: "but users won't install an app". They won't install an app because people keep luring the away with insecure web-page based secure messengers.
There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversations, let alone without having to install anything new and try to convince their friends to use it too. This is made with them in mind.
I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually makes a web application safer for this use compared to creating a native application on the basis that if the native application is exploited, all user-mode data is now at risk. At least with the containment of the browser, the only things at risk are (potentially) your messages assuming successful XSS.
So long as the proper mitigations are in place, it really makes no difference. The largest future improvement for Cyph in the future would be to incorporate one of the CSP2 changes for more safely allowing inlining, notably hash-src. However, since CSP2 adoption isn't all that widespread quite yet, it's better to hold off until the implementation details between the largest browsers are equalized.
Edit to address your last paragraph: "[Users] won't install an app because people keep luring the away with insecure web-page based secure messengers."
Native encrypted messaging apps have been around for a while and haven't really caught on unless integrated into existing apps a la iMessage. That's where the need for in-browser apps is coming from.
My 2 cents. I'm likely entirely wrong; you've got more experience in general AppSec than I do, so my assumption of risks here might be off-base.
If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything.
If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page.
For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.
> all of them are likely to be able to compromise a messaging application that boots from a web page.
All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics.
I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said...
> and today, they need to install software to do [address serious adversaries].
I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration.
Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.
all of them are likely to be able to compromise a messaging application that boots from a web page
So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app?
The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way.
Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).
Zero is the number of software security researchers who would agree with you that a program booted from a web page via content-controlled Javascript code running in a browser tab is as secure as a native application.
Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint:
Sure, "zero", except the researchers who actually audited it and concluded exactly that: http://pastebin.com/HcL5bneg
Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail.
This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.
That's not what that message says, but maybe you could email your auditors and ask if they'd stand by the assertion you're making that native apps aren't safer for cryptography than browser apps.
As for the rest of it: I'm sorry you feel that way, but I've reached a point in my message-boarding career where, after many, many years of fighting the good (then marginal then tedious then bad) fight, I'm just not going to litigate this issue anymore. What you're doing is now is a bad idea, and for the sake of your users I think you should port to a browser extension (and, eventually, to a native mobile app) as soon as you possibly can. Maybe you can improve your security before your popularity gets out of hand and avoid the fate Telegram seems to be falling into.
When new web standards make browser crypto viable, I'll acknowledge them. Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
Chrome extensions are HTML5/JS... which wouldn't stand to your own argument.
> Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
You're saying IE6 and Firefox 1.0 were better for cryptography than our environment today? We've got effective standards like CSP and CSP2 for restricting code execution client side, SRI for validating resources hosted beyond trust boundaries, HPKP and HSTS for ensuring trust on TLS connections, and we have cooperation between major browser vendors to implement patterns like HSTS preloading and even certificate preloading for certain sites such as Twitter, environment sandboxing introduced as early as 2007, and your assertion is that the browser environment now is less hospitable to cryptography than in 2005?
You were right a few comments ago; there's no point debating this any further. I have to do some shoveling anyway.
I'm just not sure how you expect me to take your position seriously and blindly follow it, when your reaction to the information I've presented is to pretend that there's literally no difference between WebSign/Cyph and something like MEGAChat. I felt that the "HPKP suicide" hack (which is something enabled only by recent Web standards) was a stroke of genius on Cure53's part; in the very least generous interpretation, it obviously still isn't equivalent to the security of a vanilla Web application, which you seem to be suggesting.
As far as Mario's statement, while you're correct that it doesn't explicitly compare WebSign with installing a native app, it was made in the context of a threat model that assumed that level of security. This is why the one WebSign bypass exploit they found[1] was flagged as High — in any other Web app it would simply be a given that the server can serve new code.
re: browser extensions, what WebSign provides is comparable, except without sacrificing the security benefits of the restricted privilege set of a standard Web context. (i.e. A vuln in Cyph wouldn't put more than just your browser tab at risk.)
---
1: This was immediately fixed, and then the HPKP rotation scheme Cure53 came up with was soon added on top of that fix.
So, if you're still reading this thread, I have one last question: what advantage do you think a browser extension has over WebSign as I've described it?
I'm asking explicitly because, since you still maintain that the extension model is objectively more secure, at least one of us is clearly missing something very important.
Hey Thomas, thanks for the comment; I'd been wanting a chance to get your thoughts on WebSign for ages!
While our audit demonstrates that this scheme shouldn't be expected to be cracked without a critical vulnerability making its way into your browser, it does introduce some odd dependency relationships that certainly introduce new attack vectors not seen in the TOFU property of regular standalone apps.
For example, given that the NSA can be assumed to be indiscriminately passively logging all HTTPS traffic, imagine that one day they gain the capability to break 4096-bit RSA: in a targeted attack scenario, suddenly they can now go back through their traffic logs, find whichever public key is pinned in a particular Cyph user's browser, compute the associated private key, and undo method #2 as descried in the linked reddit comment (the "permanent offline" trick), which gets them half of the way toward completely breaking that user's TOFU.
That having been said, I consider it a perfectly acceptable and pretty neat solution to the problem. Is there something else you're seeing that makes you object to it?
Edit: If your objection isn't to WebSign but to the Web / JS as an execution environment in general, I'll throw in a link to this note on how we're mitigating those traditional risks while also benefitting from the sophisticated sandboxing of modern browsers: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...
Not denying the increased attack surface, but that bypass was immediately fixed and verified by Cure53 (so no known vulnerabilities exist); furthermore, as you'll see in both our foreword to that report and the linked reddit comment, the current version of WebSign actually no longer has that general flaw.
Breaking WebSign would require defeating TLS public key pinning (which is a security feature), thanks to the technique that an email I just received so perfectly referred to as "HPKP suicide".
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?
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.
You should stop deploying this app from a web page. Altogether. And soon. Port it instead to be a Chrome extension that users install.
I'm sure you're not hurting anyone right now. But you've built the kind of application that will, if it ever gets to be very successful, probably get people hurt. Better instead to work on something that will help people more as it gets more popular.
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.
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".
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.
> 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".
I felt that that was a perfectly fair statement on Thomas's part. It's fine if people are willing to risk their lives for a cause, but they shouldn't be misled into outright sacrificing their lives because someone irresponsibly marketed a tool as being suitable for a particular purpose.
I'm also not sure where you get the impression that Cyph is currently at an "alpha" stage, but I'm going to have to disagree with you there too. Do you have more specific feedback, and/or did you run into a bug while using it?
Cyph looks great but there are a number of secure applications that only work on desktop or only work on mobile and I'm yet to see one that does both.
Cyph of course runs in a mobile browser but unless I missed something, it doesn't support notifications, which are important. Is there any chance of Cyph supporting push notifications on mobile devices in the future?
Which browser are you using? I'll have to test to confirm in iOS Safari, but the notifications at least work fine for me in Chrome and Firefox on Android.
However, native mobile apps are definitely on the roadmap.
Note in particular that the current system does not have forward secrecy. Near the end of the post:
> Then we plan to launch a 'Whisper Mode' for additional protection when in instant messaging sessions (e.g. message transcript/order consistency, delivery assurance, forward secrecy, and some others).
This is what I was working on at MEGA, but recently they decided to stop funding me, and I'm under the strong impression that nobody else there is working on this. So it's unclear that they have a concrete time frame for it.
Have you taken a look at Cyph (mentioned elsewhere in this thread)? Their app is also basically cryptocat, but they've taken the time to engineer an interesting solution [0] to the "Trust on Every Use" problem that secure web applications have.
Of course, you still have the problem of deploying a secure application within the attack surface minefield of a web browser, but that's a separate issue.
Secure messaging has to work. All the time. If your threat model is criminals, Gchat will protect you just fine. You use encrypted messaging to prevent governments from reading your messages. Look at the Telegram/Iran fiasco for an example of this.
So: my recommendation is, never use any secure messaging system that boots off a web page. No matter what they claim to do to mitigate the risk.
I'm actually, for a bunch of specific reasons, not super comfortable with browser extension applications either. But at least the browser tries to protect an extension you have to explicitly install and explicitly run.
Somewhat off topic, but does anybody remember when MEGASync (a MEGA desktop sync client) came out and the Linux source code was "on its way?" It's been over a year (maybe 2?) and I've seen nothing. I have no reason to trust the security of the file storage backend until then.
97 comments
[ 3.6 ms ] story [ 158 ms ] threadhttp://www.wired.co.uk/news/archive/2015-07/31/kim-dotcom-me...
When I want secure chat, I use Signal from WhisperSystems. Yeah it has usability issues, but it's obvious it's hard to do really secure and secret chat.
http://www.forbes.com/sites/andygreenberg/2013/04/17/where-k...
Not mentioned in the article is his involvement in the AT&T calling card fraud conspiracy (estimated losses $20 million) in the early '90's. It is that case that put him on the US Secret Service's radar and he's been on it ever since.
http://attrition.org/errata/charlatan/kimble/
I use Signal right now (from Moxie Marlinspike/Whisper Systems) and would only really consider alternatives if they were endorsed by other cryptographers I know because I really just don't have a strong enough grasp of how all the machinery interacts.
However, the NEWER versions of Signal requires access to your contact to work.
For many users that is a show stopper.
Implement a way for user to search by User ID and allow user to find each other by ID in addition to phone number.
Tried just now. It does require it and doesn't work without it.
A well-designed encrypted chat-protocol should work on any modern networked computing device, not just smartphones or computing devices linked to a smartphone.
I realize that phone numbers are probably hashed before being sent, with only local contact data being displayed, but it has people concerned nonetheless. It starts to err more towards convenience, ease of use, and network building above security.
Ricochet uses Tor hidden services to anonymise your social graph, which is something you don't do with Signal (not to mention that Signal does identity key lookups with phone numbers). I'm not sure there's a low-latency way to do VOIP anonymously. The best method I know of is to literally record and send audio files, which have a few seconds of latency.
If there isn't a good answer to key management, or my key is handled by JS, then it's a no-go for me.
If there is a half-way decent answer to key management, I ask what the threat vectors the system was designed for are. If a broad political statement is made, then I walk away.
While it doesn't actually vet the technical merit of the code, I feel it catches a lot of funniness.
The problem with key management is that everyone tries to solve the management problem with a single solution. A single method will always have to make choices about the threat model, which can only truly be known by the user. A single user can even have more than one threat model, depending on what they are doing.
What we need instead is some sort of configurable layer that allows the user to specify how keys should be managed by selecting what they want to trust.
They could use a default delegation to a public trust root (the PKI model, no configuration needed) for most things. Receiving a call from the bank could instead be authenticated with the key they got when they physically walked into the local branch. Chat with their immediate friends who can exchange keys on their phone when they meet up in person is easy, and a web of trust can extend that to a friend-of-a-friend. People understand the concept of vouching for someone, and over time more than one method can be used to cross-check.
Key management shouldn't be "PKI vs web-of-trust vs out-of-band-keybase-style vs manual-key-exchange vs ..."; it should be "all of the above, with the chain-of-trust exposed". Anything else is making assumptions about what the user's current needs.
Don't get this wrong please: this is still probably THE best solution right now, which simply as well has its security limitations, right?
Is there any work ongoing on a kind of "verification process" for Apps like these? How can an end-user tell if the binaries running on their device are untempered with?
/sorry for hijacking ;)
(Also: I think this question is mostly independent from the disagreements between moxie and f-droid - they were regarding other issues.)
Is it a problem with C/C++ in particular, where toolchains are complex? Or would non-reproducible also be a problem e.g for a Java library?
Googling reproducible builds mainly gets you Debian info, not a general description of the issue
For example:
A good article on this can be found here: https://blogs.kde.org/2013/06/19/really-source-code-softwareWe control the whole packaging/signing framework (WebSign), so there isn't any need for us to wait on a third party to roll this out.
I'm sure that these solutions are a lot more secure than completely unprotected alternatives, but am I wrong in assuming that if you want secure and private communications, the following principles must be met at the least?
* The protocol used must be open, standardized and implementable by others
* Widely endorsed by cryptography experts
* An implementation must be available and developed as free and open source software
* End-to-end encryption is used for the contents of the conversations, private keys do not leave the user's computing device
* The protocol must not have any technological barriers that prevent an implementation from working on any modern operating system (i.e., a phone number is not required)
* The protocol must allow for a complete communications network (clients and servers) to be implemented without the need for centralised third-party services
(The last point probably implies federation.)
For e-mail, OpenPGP meets these requirements. For chat, XMPP has Off-The-Record messaging.
Some of the above points are hostile towards any party that creates secure communications tools with the intent of growing a large user base for economic purposes. Call me a sceptic, but this is probably why use of these protocols and principals is limited to security experts and software developers who understand these principles — for anyone betting on creating the next WhatsApp in one of the mobile walled gardens embracing the whole list means risking losing your potential advertising eyeballs to alternatives.
Of course, there is also the matter of infrastructure. A lot of people expect to be able to use these tools for free, but that implies that someone is paying for the hosting of (relay) servers.
OpenPGP is impossible for most email users to get working correctly.
Remember that most people don't even know the difference between CC and BCC.
Here's an example of de-anonymising anonymous messages, supossedly from clueful users: https://ritter.vg/blog-deanonymizing_amm.html
Difficult perhaps, certainly not impossible, and quite feasible if someone helps you. But I am not suggesting OpenPGP as an alternative for chat-apps for everyone; only for those who understand how to use the technology properly.
I mention OpenPGP and XMPP OTR because they are examples of open standards that do fulfil the principles outlined above. That is, to illustrate that it is certainly not impossible or infeasible to create such a technology. What is missing is a technology that does that, and allows anyone (regardless of technological prowess) to use them safely. It is a tough problem though.
In kmail, to use GPG keys, I need to go to Settings -> Configure -> Identity -> Modify -> Cryptography, change my signing and encryption keys (and it supports PGP or MIME) and then, since I don't already have keys, need to open Kleopatra, the KDE GPG client.
Kleopatra uses keys.gpupg.net as its default keyserver, and you can do file -> new certificate to make one. Its a wizard, so you go step by step, setting up a password for the cert along the way. You also make a revoke cert you save somewhere.
Once you made the key, you need to export it to the server. And you probably want to make a signing and encryption key, since if you got this far you are already a super techy nerd and that is what makes my point right there.
If you want normal people to be able to use gpg in kmail, there needs to be a wizard just like the "add account wizard" called "Setup GPG" that searches for keys that match your email address first in case you already have them and if there are none generates you new ones and just asks you for the password. It handles the propagation and importing of keys itself because thats not something a user should be dealing with unless they need to.
And even that is unlikely to happen - you want the GPG setup to really be a part of the first-start of Kmail process. Like the first time you open the program and get the "add account" button you should also get "setup security".
But even if you can get people making keys, the UX sucks because it makes them enter a password every time you send an email. You should be able to do what kwallet recently did, and bind the unlock key to your GPG keys to your user session so that when you enter the desktop via SDDM it unlocks your GPG keys just like it unlocks your wallet. Then people can use secure email whenever they want without any bullshit.
There are even more UX nightmares - getting your keys across different computers, easily revoking them if they get compromised, even knowing what that means.
By comparison OTR in Telepathy is almost usable. In KTP you just hit the "use OTR" button and if your chat partner does the same it automagically generates and shares the keys, no user interaction required. The only downside is that you don't get local logging of your OTR conversations - that should definitely be an option, maybe even encrypt them with your kwallet keys! Eh, eh?
But these kind of UX nightmares keep secure communications from being a thing. Mumble is literally the best security solution I have, because I can get a letsencrypt cert, run my own server, put on a password, and anyone chatting on it has perfect security in voice and text - the whole thing is encrypted, I can do my own trust network based off my x509 cert, and it even supports pinned users so nobody can impersonate anyone else.
But I say that its the best because for anyone I invite, they literally just need to enter the password I give them to my server. Sure, its problematic to give them the password if you don't have a secure communication link beforehand, but I guess thats what OTR is for! Oh drat...
The perfect PGP secure email client would be cross platform and provide its own email server. The client has included trusted keys to communicate with upstream, but when you first start it you make your account and that generates you a signing and encryption key based off your password, backs it up on their server (remember, its password protected, they cannot access it despite backing it up) and then whenever you sign in on other device your keys are downloaded and just work.
This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
And I worry even that is too complicated for my grandmother to be willing to put up with to stop the NSA from reading her emails.
> This basically turns PGP into username / password, but the only alternative is to use wifi to send your keys between devices when you first start your client of choice - IE, you start it for the first time, it says "do you already have an account? You say yes and it simply asks which PC on the lan has your keys, it communicates with it, you confirm on the other computer to send the keys, and it synchronizes your keys cross-device peer to peer.
Or you could carry your keys around with you on a physical smart device that communicates over usb or nfc. This ux already seems to work well in corporate environments, it's just a matter of convincing consumers it's worthwhile and vendors to bake support into their products.
However Mumble is not a valid comparison, because Mumble is not End-to-End encrypted. The security of Mumble amounts to an encrypted connection to the server, protected by a password; from this POV Mumble is no more secure than Facebook or Hacker News.
"You're browsing without Javascript! If you have no idea what that means, you should ask your technical friend about it. Otherwise - kudos."
No, kudos to you. I could count on one hand the number of times I have been congratulated by one of these capability detection messages for browsing without Javascript.
Perhaps the combination of federation and OTA can be given an impressive sounding name, a nice logo and a foundation (everything needs a foundation). Then the name/logo can show up on feature lists. People love features...
If you're looking for actually secure communication that runs as a Web app, my startup Cyph (cyph.com) is the only option that exists. This is because we put in the time to build it correctly; the root page of our application is a permanently pinned (TOFU) bootstrap that validates/executes signed application packages, and the scheme to accomplish this was rigorously vetted in a 12-day audit.
Edits:
* Here's how it works: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...
* Here's Cure53's audit report: http://cyph.team/cure53report
Vetted by whom? It would help build trust if there was a public report on the strength of your implementation available somewhere.
(That link contains a page of additional context to explain the findings, e.g. some were pre-production.)
If you could post a link explaining how this tech works, I would be very interested in reading about it...
That having been said, my cofounder and I are the only two people with the keys to sign releases (and as long Cyph exists they'll only ever be held by either ourselves or an equally small set of individuals deemed worthy to trust with our lives) — so you shouldn't ever expect that kind of deliberate backdoor, even if I end up in prison for refusing. We're also maintaining a strong focus on OpSec of these keys, e.g. we're about to migrate the release signing off of our (full disk encrypted) personal laptops to a dedicated air gapped environment.
As far as how the tech works, we don't have a great explanation on the website yet, so this reddit comment will have to do for now: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp.... There's also a visualisation in http://cyph.team/producthandout, if that's helpful.
As for opsec on keys... the only thing making key extraction remotely difficult by a state actor is probably some form of hsm - but recalling the xbox 1 crack, I don't know how well even those stand up in practice. For everything else, I assume you're just a sneak-and-peak warrant and some cameras/listening-devices away from sharing your passphrase.
Don't get me wrong, I think it's great that people are working on secure chat applications. I just think one needs to be very careful making claims that end up on the side of being secure against state actors.
Also agreed on all other counts; if all else failed, I have no doubt that a state actor could certainly extract our keys through targeted physical surveillance and/or force, which I don't think there's really a good workaround for short of raising our own army to protect a private bunker for air gapped release signing.
What this first iteration of the air gapped environment is meant to accomplish is to simply make it that much harder. Sure, the CIA can still probably break into my home and set up a surveillance camera to steal the encryption passwords of my keys without my noticing, but what they will no longer be able to do is steal them by tampering with my laptop while my head's turned in broad daylight.
As Cyph continues to grow as a company, we expect to have the resources to implement increasingly sophisticated OpSec measures.
From the actual conclusion: "Cyph claims to provide security from a broad range of cryptographic attacks"
Whats the deal here?
The thinking there was that there wasn't a good way to quote any single part of the report without introducing unnecessary and/or fishy ellipses, because although the point of the rest of the conclusion is that it confirms the claim made by Cyph, there wasn't a readily available standalone sentence in there which could go on the front page.
Background: I advised Cyph on AppSec topics on behalf of Mach37 as a mentor, and I helped coordinate the Cure53 pentest. I'm the one who sourced the quote.
Give me a few moments (or days; we'll see) for me to find a good way to publicly and non-repudiably present the exact source of the quote.
Edit:
Signed statement: http://pastebin.com/HcL5bneg
Key: https://keybase.io/cure53
Hat tip to Mario (https://twitter.com/0x6d6172696f)
This stuff has to work. The adversary for secure messaging is world governments. If all you're worried about is criminals, Gchat will do a fine job of protecting you. For a vivid example of what I'm talking about, see the Telegram/Iran fiasco.
It's hard enough building secure messaging in a native application; there are lots of details that are not easy to get right (as Cure53 demonstrated to your team).
Bluntly: I feel that it's irresponsible to add to that portfolio of difficulties the added attack surface of content-controlled Javascript.
The reason people build services like this is that users will prefer them to (more secure) native app alternatives. It's easy to see why. The common response to this observation is: "but users won't install an app". They won't install an app because people keep luring the away with insecure web-page based secure messengers.
I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually makes a web application safer for this use compared to creating a native application on the basis that if the native application is exploited, all user-mode data is now at risk. At least with the containment of the browser, the only things at risk are (potentially) your messages assuming successful XSS.
So long as the proper mitigations are in place, it really makes no difference. The largest future improvement for Cyph in the future would be to incorporate one of the CSP2 changes for more safely allowing inlining, notably hash-src. However, since CSP2 adoption isn't all that widespread quite yet, it's better to hold off until the implementation details between the largest browsers are equalized.
Edit to address your last paragraph: "[Users] won't install an app because people keep luring the away with insecure web-page based secure messengers."
Native encrypted messaging apps have been around for a while and haven't really caught on unless integrated into existing apps a la iMessage. That's where the need for in-browser apps is coming from.
My 2 cents. I'm likely entirely wrong; you've got more experience in general AppSec than I do, so my assumption of risks here might be off-base.
If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page.
For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.
All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics.
I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said...
> and today, they need to install software to do [address serious adversaries].
I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration.
Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.
Not interested in this argument, sorry.
> Not interested in this argument, sorry.
You shouldn't have started it then.
So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app?
The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way.
Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).
Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint:
b2b90c80626b1ba036bd87abc0741e1c69d2f6da398018de00b52a3cb9fe2121
Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail.
This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.
As for the rest of it: I'm sorry you feel that way, but I've reached a point in my message-boarding career where, after many, many years of fighting the good (then marginal then tedious then bad) fight, I'm just not going to litigate this issue anymore. What you're doing is now is a bad idea, and for the sake of your users I think you should port to a browser extension (and, eventually, to a native mobile app) as soon as you possibly can. Maybe you can improve your security before your popularity gets out of hand and avoid the fate Telegram seems to be falling into.
When new web standards make browser crypto viable, I'll acknowledge them. Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
Chrome extensions are HTML5/JS... which wouldn't stand to your own argument.
> Unfortunately, the 10 years since 2005 have made browsers less hospitable to cryptography.
You're saying IE6 and Firefox 1.0 were better for cryptography than our environment today? We've got effective standards like CSP and CSP2 for restricting code execution client side, SRI for validating resources hosted beyond trust boundaries, HPKP and HSTS for ensuring trust on TLS connections, and we have cooperation between major browser vendors to implement patterns like HSTS preloading and even certificate preloading for certain sites such as Twitter, environment sandboxing introduced as early as 2007, and your assertion is that the browser environment now is less hospitable to cryptography than in 2005?
You were right a few comments ago; there's no point debating this any further. I have to do some shoveling anyway.
The mic drop at the end of your comment would have been more dramatic had you been replying to a comment addressed to you.
As far as Mario's statement, while you're correct that it doesn't explicitly compare WebSign with installing a native app, it was made in the context of a threat model that assumed that level of security. This is why the one WebSign bypass exploit they found[1] was flagged as High — in any other Web app it would simply be a given that the server can serve new code.
re: browser extensions, what WebSign provides is comparable, except without sacrificing the security benefits of the restricted privilege set of a standard Web context. (i.e. A vuln in Cyph wouldn't put more than just your browser tab at risk.)
---
1: This was immediately fixed, and then the HPKP rotation scheme Cure53 came up with was soon added on top of that fix.
I'm asking explicitly because, since you still maintain that the extension model is objectively more secure, at least one of us is clearly missing something very important.
While our audit demonstrates that this scheme shouldn't be expected to be cracked without a critical vulnerability making its way into your browser, it does introduce some odd dependency relationships that certainly introduce new attack vectors not seen in the TOFU property of regular standalone apps.
For example, given that the NSA can be assumed to be indiscriminately passively logging all HTTPS traffic, imagine that one day they gain the capability to break 4096-bit RSA: in a targeted attack scenario, suddenly they can now go back through their traffic logs, find whichever public key is pinned in a particular Cyph user's browser, compute the associated private key, and undo method #2 as descried in the linked reddit comment (the "permanent offline" trick), which gets them half of the way toward completely breaking that user's TOFU.
That having been said, I consider it a perfectly acceptable and pretty neat solution to the problem. Is there something else you're seeing that makes you object to it?
Edit: If your objection isn't to WebSign but to the Web / JS as an execution environment in general, I'll throw in a link to this note on how we're mitigating those traditional risks while also benefitting from the sophisticated sandboxing of modern browsers: https://www.reddit.com/r/encryption/comments/4027ci/how_2_sp...
Breaking WebSign would require defeating TLS public key pinning (which is a security feature), thanks to the technique that an email I just received so perfectly referred to as "HPKP suicide".
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.
You should stop deploying this app from a web page. Altogether. And soon. Port it instead to be a Chrome extension that users install.
I'm sure you're not hurting anyone right now. But you've built the kind of application that will, if it ever gets to be very successful, probably get people hurt. Better instead to work on something that will help people more as it gets more popular.
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.
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.
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.
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".
I'm also not sure where you get the impression that Cyph is currently at an "alpha" stage, but I'm going to have to disagree with you there too. Do you have more specific feedback, and/or did you run into a bug while using it?
Cyph of course runs in a mobile browser but unless I missed something, it doesn't support notifications, which are important. Is there any chance of Cyph supporting push notifications on mobile devices in the future?
However, native mobile apps are definitely on the roadmap.
> Then we plan to launch a 'Whisper Mode' for additional protection when in instant messaging sessions (e.g. message transcript/order consistency, delivery assurance, forward secrecy, and some others).
This is what I was working on at MEGA, but recently they decided to stop funding me, and I'm under the strong impression that nobody else there is working on this. So it's unclear that they have a concrete time frame for it.
The source code and docs are here though:
https://github.com/meganz/mpenc_js https://github.com/meganz/mpenc_doc https://docs.mega.nz/chat/mpenc/
If anyone wants to continue funding this work, feel free to drop me a line.
Of course, you still have the problem of deploying a secure application within the attack surface minefield of a web browser, but that's a separate issue.
[0]: https://docs.google.com/document/d/1PGS50eZB9Ud7wVKmrc0HU_FD...
So: my recommendation is, never use any secure messaging system that boots off a web page. No matter what they claim to do to mitigate the risk.
I'm actually, for a bunch of specific reasons, not super comfortable with browser extension applications either. But at least the browser tries to protect an extension you have to explicitly install and explicitly run.