Friends: a p2p, decentralized, secure messaging platform | Hacker News Reader

Friends: a p2p, decentralized, secure messaging platform

moose-team.github.io

103 pointskmf45 comments

* No confidentiality. All communications are sent plaintext. They plan to "add support in the future when solid approaches emerge".

* Non-repudiable. Everything you send is signed with the public key on your GitHub account.

* Uses SHA1. (via the ghsign NPM module)

* Uses mDNS and BlueTooth LE and a gossip topology algorithm, so I'm not sure what would prevent a random third party from eavesdropping.

I would hesitate to market this as "secure".

Contributions welcome! This is very alpha (in fact it's about five days old). Improvements come from the community.

https://github.com/moose-team/friends/issues

Then why the hell are you advertising it as "secure"? There's utterly nothing secure about it.

From the home page:

Messages are not end-to-end encrypted, and this is not an anonymous system. See below for more details. We use the term 'secure' here to mean that we do not use plaintext transports.

Although to my admittedly meagre security knowledge, I would've assumed that "no plaintext transports" would mean it was encrypted end-to-end.

  package main
  import "fmt"

  func main(){
    fmt.Println("Hello World")
    // Contributions welcome!
  }

I really really really don't recommend outsourcing your security architecture to interested passers-by if that's going to be a core feature of your project.

But, real crypto.

(Seriously, what's that supposed to mean? Should that increase my confidence in how "secure" this is?)

Aren't WebRTC data channel encrypted by default?

http://www.html5rocks.com/en/tutorials/webrtc/datachannels/

Apparently so. It uses DTLS, but I'm not sure where the certificates for that would come from or how their authenticity is verified. If it's all self-signed, then your best solution is TOFU (trust on first use). Otherwise your confidentiality and integrity are completely dependent on your network position.

> When you send messages, they're signed with your SSH key

It seems to me that they're encrypted with your private key and paired with "username". The client then attempts to decrypt using the public key associated with that username on github.

In this system, the receiver and any MITMs (okay, so everyone) know it came from "the real grrowl according to github" — authenticated but not confidential at all.

Two things:

First, you're describing RSA signatures. "Encrypt X with your private key" means "X^D mod N" which is how RSA signatures work. In the context of RSA-based cryptosystems, it's clearer to just say "signed".

Second, the ghsign library uses the `RSA-SHA1` signer, which runs the message through SHA1 before signing it. The reason it does this is because "textbook" RSA (i.e. RSA on arbitrary messages) is vulnerable to chosen-plaintext attacks.

This is an invaluable comment — thank you.

Brings back memories of WASTE... oh Nullsoft, what happened?

https://en.wikipedia.org/wiki/WASTE

Poor nullsoft. Milkdrop is still the best music visualiser available, NSIS is still(!!!) being updated (last release October 2014), and they just did Great Work until AOL came along. So sad.

Among other, non-technical things it simply didn't scale well because of its re-broadcast nature.

BitTorrent already built something like this (but even better and more secure) called Bleep: http://labs.bittorrent.com/bleep/

More secure, while in this case is not a high bar, is just an assumption without the source code.

Neat service!

But, why does something saying it is p2p always seem to have some centralized dependency? In this case, it's GitHub auth.

It seems that the initial authentication of you are who you say you are could be done via transferring a key to someone- by email, flash drive, whatever- and then after that, as long as you could connect to them, you could talk to them- with no other dependency except the network itself, which may involves a lot of significant dependencies, or may not, e.g. a cross-wired cable.

Because key distribution is a pain. That said, it would be neat if you could choose centralized keystore. That would mean that you would get one account per online service, but the communications could be multiplexed.

Key distribution and NAT traversal. The latter is literally impossible without some kind of external third party to facilitate.

> Simply put, this is a proxy server that works behind a NAT, even when the client is behind a different NAT, without any 3rd party or network changes.

> There is no middle man, no proxy, no 3rd party, no UPnP/STUN/ICE required, no spoofing, and no DNS tricks.

http://samy.pl/pwnat/

The FAQ is great too :)

    Ok, so does this really work?
	Yes. Try it!

    I'm confused. This can't work.
	You should be, and it does work.

    But it can't. My NAT blocks incoming packets and so will the other.
	I know.

That is both brilliant and hilarious!

It's clever, but not exactly relevant to the GP's comment. pwnat requires the initiator to know the IP of the target host, so some form of external seeding is still required.

Knowing who you want to contact is usually a requirement to be able to contact them.

Something like PGP without automatic trust of new connections may work, as if cross with Facebook's friend system.

"This user claims to be Jimmy Jimson (image of fingerprint). Trusted by 19 people you directly trust, and by 250 people they trust. [add] [ignore]".

Is this feasible? I'd rather attackers social engineer people rather than subvert the technical, non-human aspects.

And like Facebook, if you see two of the same person on your Trusted list, you know one of the accounts is probably not under their control.

The number one thing I'm looking for in an open-source Skype alternative is persistent group chats with history (so when you sign in, you're still in the same group chats you were, and the history of messages that were sent in that chat while you were gone are sent to you). I'm baffled that this seemingly necessary thing is such a rare feature, and I'd be all over this project if it gets this.

Easier said than done

We thought the exact same thing, so we're creating Matrix [1]! It supports all sorts of things, but especially public/private group chats with multiple device support. We're basically a team of people who use IRC all day, so we really do feel your pain :)

[1] http://matrix.org

TextSecure has encrypted group chats. If there's any downsides there, I'd be curious to hear what they are.

irssi in tmux on a cheap VPS.

I know this might sound snarky, but this is the combination a lot of my peers and I use.

I'm wary of the "yet another proprietary new messenger", all of which are only compatible with themselves. I can not understand why none of them implement protocols all the messengers can agree upon like for example tent.io, remoteStorage or ZeroNet.

Distributed messaging is hard and a lot of people are giving it a try, leaving us with lots of different half baked walled gardens. Yes, I'm looking at you, threema, telegram and your friends...

I have approximately zero chance of getting all of my friends and family to set up their own VPSs and tmux and irssi so I can chat with them.

My senior project is this. We plan to open source it in a bit after the semester ends. You can try it out here: https://projectdefero.com/

I'll probably make a Show HN post once we open source it.

I love how you've simplified the problem space by delegating keys and key sharing to ssh and github. Nice way to get to MVP quickly!

Don't websockets require a server to work ? You can't just directly connect to an host (obviously to prevent malicious scripts, I guess) using js.

So if I understand it right, if you make a P2P app in js using websockets, it still requires a server to spread IPs between hosts. So it's "decentralized", but you could still track users since the server has everybody's address.

So when you chat, it's P2P, but when you start it up, it's still centralized.

Unlike kamdelia, bitcoin, bittorrent, bitmessage, you could still shut this down if it uses js. Not very interesting.

Exactly what I thought. WebRTC has this limitation and it's not actually possible to implement a DHT on top of it. Not sure why the developers decided to use WebRTC. I mean, it's a good transport layer for real-time communication (where bandwidth is a limited resourced), but not for decentralization.

I suppose this isn't oriented around file sharing, but it reminds me of

  * https://en.wikipedia.org/wiki/RetroShare
  * http://freecode.com/projects/alliancep2p

What are the advantages compared to Tox?

4chan trolls aren't actively trying to destroy it.

...yet

What's the UI? I can't seem to find the package here https://github.com/moose-team/friends/blob/master/package.js...

Is it http://nwjs.io/ ?

https://github.com/atom/electron

This sounds a lot like the spirit of Skype in its early days.

I could be wrong but now that the latter has been integrated into Microsoft's tools, I think there's an open gap for what Skype used to provide: a friendly P2P chat tool.

Tox[1] is aiming to fill that gap. It works, and although it hasn't been properly audited (that I know), most people agree that it's reasonably secure and anonymous. It's also completely p2p with no federation of any kind.

It has a ways to go in the way of frontends and mobile support, but it works. The biggest feature it's missing is proper synchronization of your profile between devices (which is a development priority). That and it has a small network of users, so you won't be talking to your mom over Tox.

[1]: https://tox.im/

Interesting, but I'll stick with Twister: http://twister.net.co/

Any differences from Wicker?

Reply on news.ycombinator.com