
Show HN: A decentralized social network with end-to-end encryption - mschultheiss
https://github.com/mschultheiss/Charme
======
tptacek
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.

Good luck!

~~~
mschultheiss
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 :)

~~~
tptacek
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).

~~~
mschultheiss
1\. The web crypto api was indeed made to secure communications, such as
stated by the W3C on
[http://www.w3.org/TR/WebCryptoAPI/](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 ;)

~~~
sarciszewski
> 1\. The web crypto api was indeed made to secure communications, such as
> stated by the W3C on
> [http://www.w3.org/TR/WebCryptoAPI/](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.

Shameless plug: [https://paragonie.com/service/code-
review](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()
    

Life is easier with sodium. [https://paragonie.com/blog/2015/09/how-to-safely-
implement-c...](https://paragonie.com/blog/2015/09/how-to-safely-implement-
cryptography-in-any-application)

~~~
Canada
Even if he makes all those decisions correctly the system won't support
forward secrecy.

~~~
sarciszewski
Why do you think I separated crypto_sign() from crypto_box() in my
description?

------
beatpanda
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?

~~~
Animats
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.

~~~
eellpp
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.

------
sarciszewski
[https://github.com/mschultheiss/Charme/blob/7634cd89febbe288...](https://github.com/mschultheiss/Charme/blob/7634cd89febbe28825d6d33c012c2fe4754f02c2/server/charme/lib/App/Users/UserRegistration.php#L34)

Please see:

[https://paragonie.com/blog/2015/07/how-safely-generate-
rando...](https://paragonie.com/blog/2015/07/how-safely-generate-random-
strings-and-integers-in-php)

\--------------

[https://github.com/mschultheiss/Charme/blob/c8eb501f1ac0c607...](https://github.com/mschultheiss/Charme/blob/c8eb501f1ac0c607d953aa60bc95bae6e548ad0b/mobile/Android/CharmeApp/charmeApp/src/main/java/com/mschultheiss/charmeapp/Controllers/ActivityLogin.java#L217)

[https://github.com/mschultheiss/Charme/blob/7634cd89febbe288...](https://github.com/mschultheiss/Charme/blob/7634cd89febbe28825d6d33c012c2fe4754f02c2/server/charme/lib/App/Users/UserRegistration.php#L79)

please see:

[http://codahale.com/how-to-safely-store-a-password/](http://codahale.com/how-
to-safely-store-a-password/)

[https://hynek.me/articles/storing-
passwords/](https://hynek.me/articles/storing-passwords/)

------
Swizec
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.

~~~
grandcat
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.

------
twiceaday
> [https://github.com/mschultheiss/Charme#why-am-i-not-
> allowed-...](https://github.com/mschultheiss/Charme#why-am-i-not-allowed-to-
> loose-the-passphrase)

One 'o' in "lose".

------
benwerd
Discovery is crucial.

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?

~~~
unepipe
There have to be things that are explorable and things that are not. Your
messages, your "wall" (to non-friends) etc - those can be encrypted.

your name, your city, your public posts, posts made by companies - you could
design this so those are not encrypted/are available for search.

------
dutchbrit
As someone who has been working on something similar (see old proof of concept
here: [https://ciety.com](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).

~~~
iheartmemcache
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.

------
tethra
It's a nice effort, but it's covered in warnings that say "don't use this" \-
therefore, not yet interesting.

I'm going to leave this here: [https://movim.eu/](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.

------
erikbigelow
Nice. Keep working on it. We need a solution. What's your stack?

------
rndmind
I support the idea behind this, but I love the community on Diaspora, and more
importantly it is also decentralized and open-source.

~~~
blubb-fish
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.

------
jafingi
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.

------
z3t4
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.

------
em3rgent0rdr
>> "If you want to support development and have to much money"

 _too_ much money.

------
sedatk
how is it different from diaspora?

~~~
mschultheiss
It has end-to-end encrpytion - so if you are hosted on a friend's server for
example, the friend can not read your messages, which might be useful :)

~~~
sedatk
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.

~~~
beagle3
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.

~~~
jaywink
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.

------
ex3ndr
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.

------
zitterbewegung
How do you handle discovery is it location based or in person like a darknet?

------
synchronise
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.

------
module17
End-to-end-encryption-not-secure. hmm.

------
dafrankenstein2
i did also thought about something like a P2P hybrid network

