The cryptography in this system does not appear to be safe. Apart from the fact that it's browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't), it's also using outdated RSA crypto constructions that are vulnerable to attacks.
I think you should find an expert to work on this project with you and provide the cryptographic design for you. Cryptography in a social network is like cryptography in a messaging application: it has to work. It's irresponsible to offer someone a solution for sharing secrets (with peers or with their network of close friends) if you can't keep those secrets.
Thankfully, you're not doing that yet; I think it was good judgement for you to include the "NOT SECURE" warning in the Readme.
Yes, as written on top this is a technology preview, so it is not safe yet.
Furthermore the production version will use the web crypto api.
The client software must be shipped packaged as a standalone application (Apache Cordova etc.) with integrity protection or hosted on your own server and served via https. Yeah, the goal is actually to get some feedback about the crypto design and improve it :)
Unfortunately, the Web Crypto API doesn't automatically get you safe cryptography either. It was added by the W3C to allow video vendors to implement content DRM in pure Javascript rather than requiring plugins, and so it includes a great deal of legacy crypto.
Long story short, you need an expert in cryptography to design this for you, whether or not you use WebCrypto.
This isn't something you should take risks with. It would be better to advertise a decentralized social network with NO CRYPTOGRAPHY (which is what this essentially is) than to say it has "cryptography that hasn't been audited" (which most users won't distinguish from real crypography).
1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/
(...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "
2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.
3. Here is a short description of the basic concept:
Client and server are seperated. The client software is basically what is hosted on Github.
Its source code must be protected from MITM attacks of course, so it is best to ship it as standalone, downloadable application in the final release. THE CLIENT CODE WILL NOT BE OFFERED BY A SERVER IN A PRODUCTION VERSION.
So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.
Next, you have a key directory. It is signed after every modification with a secret salt which was generated by the client (and not known by the server) at signup. The keydirectory contains all the verified public keys of the user. (Protecting it from replay attacks would be worth another essay here)
Now when you write messages for example, you get the public key from this directory and encrypt/sign it basically like in PGP. So the focus of this preview is not on the crypto primitives, but rather on the concept itself.
Edit: I hope this does not sound too unfriendly, I am very happy about your feedback and I promise I will look for further advice regarding the crypto/protocol ;)
> 1. The web crypto api was indeed made to secure communications, such as stated by the W3C on http://www.w3.org/TR/WebCryptoAPI/ (...) "Uses for this API range from user or service authentication, document or code signing, and the confidentiality and integrity of communications. "
So they say. You'd be hard-pressed to find a cryptographer that likes Web Crypto.
> 2. Yes, you are definetly right, an detailed audit of the protocol is necessary by more than one expert.
> So at sign up, the client software now generates a (RSA) public key pair and some symmetric keys used for (AES) encryption and integrity protection locally and encrypts it with a passphrase. The passphrase is only known by the user, but not by the server. The encrypted string is also integrity protected. It is sent to the server, stored there, and decrypted with the passphrase at login again. This way we ensure only the client software can see secrets, such as the private key, but not the server software.
Are you going to build it in, say, Electron? That's pretty neat.
What padding mode are you going to use for RSA? What hash function for MGF1?
Are you going to also employ digital signatures? Will you use the same RSA keypair for signatures?
What about your other parameters? (There are attacks for e=3 RSA signatures, for example.)
What cipher mode are you going to use for AES? What key size? Are you going to MAC then Encrypt, Encrypt and MAC, or Encrypt then MAC? I'm assuming the third option.
How are keys going to be authenticated to the clients? How will they detect/prevent the server from substituting a user's RSA (eww) key for one of their own choosing?
How are you going to derive your encryption keys from the password?
Why not save a lot of time and frustration and just use node-sodium (assuming Electron of course)?
It seems like there would be a lot of uses for something like a jQuery for the WebCrypto API. There are enough ways to get it wrong, and enough commonality among 80% use cases, I can see something like this being better than the alternative.
Google's NaCL (i.e. NativeClient, not Libsodium-- awful overlap in terminology there) + Crypto_box + PPAPI seems to be really easy to implement as well as really secure, but Mozilla wants nothing to do with NaCL (again, the Google Native Client for Chrome/Chromium - not the DJB lib).
Edit: and that's what I get for skipping over half the posts in this thread. You specifically mentioned crypto_box/libsodium. No surprise there, you seem pretty well-informed from the 50% of the posts I did read in this thread ;). Zimmerman got it right amazingly right with PGP 20 years ago. The men and women at keybase.io are doing a great job trying to bridge the gap in the interim. Your route is the route I'm taking right now as I'm building out but with USB key and/or cell phone authenticators. Speaking of which, Thomas, in a few weeks if you have some spare time I'd love for you to look at what hopefully isn't a travesty of a product. (I minimized as much as I could re-using existing components with the intention of limiting the potential of bugs I could introduce, but Johnny's gonna have crypto soon if I have my way.)
Yes just something that implements signatures and private messages in the best way web crypto allows for. Bonus points for encapsulating the best practices rather than just documenting the footguns.
Isn't this the one application were JS crypto is OK? As far as I understand, that is not at all, here JS crypto is used to offload the computation from a trusted server to a trusted client and afterwards the server distributes the encrypted message further.
> The cryptography in this system does not appear to be safe.
While one of the fundamentals, I think it's fair to say that swapping out cryptosystems is 0.1% of the work, or if the communication system needs to be redesigned, 1%. There goes a huge amount of work into designing and building all the rest.
Whaaaaat. No way man. Especially if this gains critical mass before it's production-ready for whatever reason (who knows why Farmville and GroupOn hit when they did -- right place, right time) it's nothing short of irresponsible especially without a way to effectively declare the system compromised and pull the plug.
Not only that but there are real social implications in having a system that even drops the word "end-to-end encryption" in its phrasing with the whole "Why Johnny can't have crypto" adoption problem. The average engineer rarely reads the docs, my mom would never read the README.md despite the fact that it explicitly says it's not production ready. That bitter taste is left in ones mouth for years (eg. people still associate Microsoft with unstable, insecure junk a la WinME (or unstable junk like Vista RTM [SP1 was fairly stable, but Vista still is a joke]). If this is Johnny's first exposure to crypto and he's using it to Tinder girls on the side, he's never going to trust crypto again.
Push comes to shove rolling your own crypto is completely irresponsible. There are plenty of 'alternative internet' solutions out there that are doing the responsible thing and following the conventional protocols (i.e., using libraries that have been heavily vetted by those with graduate degrees in cryptography, have protocols to revoke/expire your keys in place, WoT's, etc.)
RE: Designing and building the rest -- just like one should use someone else's crypto libs, there are already tons of 'alt-internet' infrastructures that exist which do something similar. It doesn't have the novelty of a mobile app, but most of them do have the cryptographic security to make up for it. Just to name a few-- https://cryptosphere.io/ uses libsodium, https://github.com/okTurtles/dnschain is based on GPG and standard PKI, https://wiki.enigmabox.net/ (I've only audited the cjdns server but it looks real solid, granted my specialty of mathematics is a whole different branch so I'm not even close to an authority, other than I know enough not to roll my own). Then of course there's all of the Moxie-type projects out there which I'll be damned if they've got any holes in there, the dude is of DJB meticulousness
Edit: Yeah basically what Thomas said below me, re: the responsible thing to do is to advertise it as a product with no cryptography in place. Apologies for the knee jerk reaction, but secure communication is something I've felt awfully strongly about, as exhibited by my post history pretty clearly.
> browser Javascript, which can only be as secure as the server's verified TLS key anyways (and thus doesn't add any security TLS doesn't)
This is not precise. While it does not stop even the most basic active attackers, it does prevent passive logging on the server without changing the served JavaScript, therefore making undetectable mass surveillance on the server harder. The effect is analogous to the difference between TLS with and without forward secrecy: with a similar argument you could conclude ephemeral DH/ECDH does not add any security to TLS, which is not quite the case.
When you stop passive attacks, then attackers will just step up their game to active attacks.
If you want to call something secure, you need to design a threat model that doesn't involve an attacker with one arm tied behind their back. That doesn't serve anyone's interests, except maybe the blackhats'.
> When you stop passive attacks, then attackers will just step up their game to active attacks.
Not always. It often changes the economics of the game. Especially when facing mass surveillance, considering the potential risk of detectability. Just because some attackers can step up their game for some targets, it does not imply they will do the same for all targets.
> If you want to call something secure...
I don't disagree with your point of view about what can or cannot be called "secure". One can debate that definition. However, stopping passive attackers is often NOT useless and it does add value. Security is not a binary proposition.
> Do you know what WebCrypto adds that TLS doesn't? Nothing.
No, consider this: an end-to-end encrypted messaging web page delivered over TLS that stores keys in browser local storage.
A passive attacker that can see the incoming traffic on the server but does not want to alter the JavaScript sent to the clients will never see the messages. I argue this is weak but not useless.
(I would argue all TLS encryption in the browser is, in a sense, opportunistic to a certain extent, since very rarely people look at the address bar, effectively making it unauthenticated.)
"Cryptographically secure" sounds like a vague thing you bring up here. To me, it sounds it is by definition secure (and cryptographically so, if they use cryptography) against passive attackers (and probably nothing else), but I am not really debating abstract and fuzzy definitions here.
My objection is very concrete: to say whatever uses JavaScript cryptography is as secure as TLS is false. Precisely, what it means is for all threat models imaginable, if you can somehow subvert TLS, you can always break the JavaScript crypto, and this is obviously false at least for one scenario I described in the other comment. We could reasonably debate the likelihood of the scenarios, but it's really hard to argue the mathematical equivalence of the two.
I want this to work so much. So many people have tried this, and I have signed up for, or self-hosted, every single one of these things, and even convinced my friends to join a few. None of them ever take off. How is this different?
Yes. There's Diaspora and Frendica already, with maybe a few hundred users.
To launch something like this, you need to figure out some way to get a user base, a user base that people will want to connect with. Something like
- Ivy League students (hey, it worked for Facebook.)
- VC, angels, investors, and startup CEOs. (They might like something with more security, especially since they might be planning to take a bite out of Facebook or Google.)
- Political groups, where there are communities of fund-raisers and lobbyists, people trying to get things done together and concerned with others not listening in.
Consider targeting groups that involve people working together to do something. They need to-do lists, spreadsheets, scheduling tools, and other collaboration support. Basically Box.net's feature set, but without Box, Inc.
Its a big leap to jump from a centralised social network to a truly distributed self hosted network. The missing link seems to be the semi-central ones, like having few central hosts which allow users to flow between them. Get the protocol to evolve and user adoption to happen on this and subsequently allow anyone to plugin their self hosted server, if they want to and still allow full network discovery across the hosts all over world.
It seems like there are far more programmers creating back-end for this kind of thing than there are designers working on good concepts and front-ends.
I'd build it on top of WordPress as a plugin. Then most of the interface decisions are done, the community is already there, and installation takes about 3-4 clicks.
This is a serious question, because it's the situation I'm in: Why would somebody who is techy enough to use a decentralized social network, not just use IRC?
I have a group of techie friends. We started a "private" IRC channel in 2010-ish and so far have been unable to find something better. Modern clients embed images, embed video links, and so on. We have bots that handle upvotes and offline messaging and a few other things. We even have a thingy that shows history (and most modern clients do that anyway)
None of us would be willing to self-host anything. Too much effort.
Am I misunderstanding how decentralization works for Charme? Is it more like hosting my own website, or more like using git?
I like the idea. I worry about moving my existing social capital.
In my opinion, IRC does not have the features that Charme can offer right now (not looking at the security perspective right now):
It allows smart ways to filter your friend's messages. For example, you could filter for people driving from point A to point B. Considering some hundred friends within one group (like in FB), you could handle the massive amount of messages manually any more.
So, these context things in Charme look very promising.
For hosting I agree that it might be a problem. But normally, you always know one of these techy guys :)
However, I completely agree with the last part: moving a user base is very tough or even impossible.
A social network can be thought of as a kind of search engine: you're trying to find people, posts and resources that are relevant to your interests.
On the other hand, a social communication app works by allowing you to connect to your existing friends. So for example, with an app like Peach, finding new people or searching for posts matters less.
The really hard question for the first case is: how do you combine searchability with end-to-end encryption?
As someone who has been working on something similar (see old proof of concept here: https://ciety.com - sorry for the expired ssl certificate), I applaud your efforts.
I have learned a lot since the version above (a lot has been changed) and I see room for a lot of improvement. I also have a nice desktop client on the way since you shouldn't be doing crypto in the browser/javascript, feel free to add me on Skype (samgranger) or email me: sam.granger@gmail.com - I'd be willing to give you some pointers. I'll be releasing v2 soon (which will also be open source).
Not sure if you missed it but letsencrypt.com has first party certificates for free on 90 day renewal terms. Encrypt everything, and then some.
It's at the OS level too, at least on Win10, as I was going through the mmc Cert module to see what was in there and lo-and-behold. I had thought it was just an agreement amongst the three browser developers. I should check my Mac to see if Apple pushed an update too.
Movim is a social networking client that is based on standards. It uses XMPP under the hood, and utilises the XMPP standards for instant messaging, multi-user chats, and microblogging (amongst others). It covers all the major features of facebook (IMO) as well as being federated, so that people can run their own nodes.
The big downside of it is though that your stuff is potentially stored on someone elses pod - okay, you can create your own server for the pod etc but this won't help you if messages from you are insecurely stored on some strangers server.
The solution would be to (somehow) introduce asymmetrical encryption for the content.
You really need to look on the security perspective to harden it. When it's marketed with security in mind.
And there's so many things wrong with the PHP syntax etc. as well as you have committed the entire Composer vendor/ folder. Put it in gitignore and remove it. You should not commit dependencies to your code base.
I'm also writing a paper on decentralized social networks. And the biggest hurdle I think is to make currently available technology stacks easier to use for non technical users.
in that case, wouldn't it be better to focus on adding e2e to diaspora? or is there an architectural limitation with it? that seems a lot of redundant work at the moment.
Without knowing anything about the technical difficulties, I would argue that Diaspora as a brand is already dead -- associating with it is basically a guarantee of no users.
That is so untrue. Diaspora is doing better than ever, after the unrealistic burden of killing Facebook was gotten out of the way. Now it is "just" a well functioning network with tens of thousands of active users and an active development team.
One main problem is that you have to make passwords recoverable. In real world message like "warring! we can't restore your key!" just doesn't work at all. People ignore it and still want you to recover their keys. Also forcing people to have password is also very vulnerable.
Is there a reason why this still relies on a server? I would have thought that the better option would it to be completely P2P, without any servers whatsoever.
I think you should find an expert to work on this project with you and provide the cryptographic design for you. Cryptography in a social network is like cryptography in a messaging application: it has to work. It's irresponsible to offer someone a solution for sharing secrets (with peers or with their network of close friends) if you can't keep those secrets.
Thankfully, you're not doing that yet; I think it was good judgement for you to include the "NOT SECURE" warning in the Readme.
Good luck!