Show HN: A decentralized social network with end-to-end encryption
github.com
github.com
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!
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).
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 ;)
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.
Shameless plug: https://paragonie.com/service/code-review
> 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)?
- Transport: crypto_sign() + crypto_sign_open()
- Encryption: crypto_box() + crypto_box_open()
- Key derivation: crypto_pwhash() + crypto_box_seed_keypair()
+ crypto_sign_seed_keypair()
- Salts, keys, nonces, etc: randombytes_buf()
What you want instead is a library that carefully selects primitives with an emphasis on:
1. Security
2. Performance
3. Ease of use
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.)
Heh, thank you. :)
> 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.
If he doesn't, feel free to ping me. ;)
The failure of current crypto experts to create a usable crypto story is 100% why we can't have nice things.
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.
You just admitted that it's useless!
https://adamcaudill.com/2014/02/25/on-opportunistic-encrypti...
No, I do not believe stopping passive attacks is useless.
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'.
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 stops all passive attackers and most active attackers? TLS.
Do you know what WebCrypto adds that TLS doesn't? Nothing.
That's why this is useless. Just use TLS correctly and you're better off.
Now, reframe this as "desktop application that uses libsodium in a protocol designed by cryptography engineer" and suddenly my interest is piqued.
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.)
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.
Huge red flag.
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.
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.
Yeah, that would be bad. Still, I think that with the warnings in place as they are, someone is going to notice and fix it way before that happens.
> my mom would never read the README.md despite the fact that it explicitly says it's not production ready
No, but anyone deploying it would. Your mom is not going to deploy this on her servers, is she?
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.
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.
Please see:
https://paragonie.com/blog/2015/07/how-safely-generate-rando...
--------------
https://github.com/mschultheiss/Charme/blob/c8eb501f1ac0c607...
https://github.com/mschultheiss/Charme/blob/7634cd89febbe288...
please see:
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.
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.
One 'o' in "lose".
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?
your name, your city, your public posts, posts made by companies - you could design this so those are not encrypted/are available for search.
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).
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.
I'm going to leave this here: https://movim.eu/
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 solution would be to (somehow) introduce asymmetrical encryption for the content.
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.
too much money.