
Ricochet: An encrypted, anonymous IM client built on Tor hidden services - synchronise
https://ricochet.im/
======
sarahj
Reading over some of the specifications - I really like this approach - I
think this is probably the closest I have seen to a truly distributed approach
to IM at the protocol layer.

If anyone would like to try the chat interface my address is
ricochet:qn6uo4cmsrfv4kzq

~~~
frevd
Now that you associated this address publicly with your profile on HN you
compromised anonymity already.

~~~
mschuster91
Why? It will still be private who has conversations with whom and especially
the content.

~~~
SoreGums
so it's not like blockchain where if you know the realid of addresses you can
follow where the coins go.

from first glance i was curious about this aspect. if a connection exists, the
end points are known or unknown? if they are known and there is a db of
endpoints to realids then these know endpoints are no longer anonymous...

i get that the content is unknowable due to encryption - that's fine. the
endpoint identification though, seems pretty cool if this is truly anonymous.

~~~
mdasher
There is no realid. When you are chatting with someone through Richoet you are
connecting to a Tor hidden service that is running on their system. Tor goes
to great lengths to hide the true identify of both the client and the service
when your using hidden services.

~~~
SoreGums
i've obviously misread what a TOR hidden service is then (and how connection
are established between two end points), will go read again later.

my current understanding is even though an IP Address might not be connected
to me personally, all the routers in between me and the destination server
know that my IP wants to connect to dest IP . Thus there was some
communication between my IP & dest IP at some time, and is in a log if routers
keep logs (or any other device that is physically connected to the same
physical path that my packets took)

Sounds like TOR hidden services don't create breadcrumbs like this then.

------
tobias2014
Sadly I2P is missing such a maintained messenger. I am only aware of this
working, but abandoned one:
[http://echelon.i2p.xyz/qti2pmessenger/](http://echelon.i2p.xyz/qti2pmessenger/)

~~~
synchronise
Tbh I2P would be a more suitable platform to build a messenger similar
platform to Ricochet, in fact there was an effort to get exactly that up and
running called Invisible.im, but that later merged with Ricochet to avoid
duplication.

But as I2P is the ideal network, I2P-Messenger is far from the ideal client.
Most of the code is a mess of if else statements and there are no other
features than being able to chat 1on1 with another I2P-Messenger instance.

------
unicornporn
This did pretty much the same thing:
[https://github.com/prof7bit/TorChat](https://github.com/prof7bit/TorChat)

Had a good OS X client. Seems it has been abandoned though.

~~~
FungalRaincloud
It is, I believe, still used, but the lack of development is certainly a
concern. I believe it's every bit as common to create disposable accounts on
other chat clients and just enable OTR[0] for whatever protocol you use.
Traffic is typically still routed through Tor, and since the account is
disposable, you shouldn't need to worry about it being linked to you. Only
true concern is that the protocol you pick might not be running on a hidden
server, so the records of that server could be subpoenaed. However, for
example, you can pick hidden xmpp services, which means you only have to trust
that the service itself is being run by entities who have no reason to
compromise your endpoint or manipulate your chat experience. It means you have
to be on the same server as the person you're looking to contact, and it means
that you need a way of establishing the identity of the person you're trying
to talk to. OTR does this by having secret questions and answers, which have
to match at least the first time you talk to someone. I would personally
combine this with PGP key verification, if the person has a known public key.
It's easy to see someone type in the answer to the secret question, or even
guess it if the person doesn't think far enough ahead to make that unlikely,
but (hopefully) much more difficult to grab the person's private key and
passphrase.

[0] [https://otr.cypherpunks.ca/](https://otr.cypherpunks.ca/)

------
eosrei
Reminds me a lot of the Tox project, a peer-to-peer encrypted skype/IRC/IM
replacement:
[https://github.com/irungentoo/toxcore](https://github.com/irungentoo/toxcore)
Tox optionally supports Tor:
[https://wiki.tox.im/Tox_over_Tor_%28ToT%29](https://wiki.tox.im/Tox_over_Tor_%28ToT%29)

~~~
sitkack
This makes the same mistake as Tox, unsafe native code. These kinds of
projects need the same level of detail and provable correctness that goes into
space or nuclear control systems.

~~~
Jfreegman
Far from having comparable resources to billion dollar space and nuclear
corporations, FOSS developers often have no funding at all and work entirely
in our spare time, for free. Any attempt to accomplish "provably correct" code
with the same attention to detail that goes into space or nuclear systems
would kill a typical FOSS project before a single line of code ever got
written.

~~~
verbin217
This is likely true today but it's increasingly false. Massive efforts are
already underway to develop tooling and methodology for this purpose. Once
completed the applications developed with them will be significantly easier to
produce. Also, since they're provably correct the "maintenance" metaphor is no
longer applicable. What we need is provably correct code generation for the
output of theorem provers like Coq. These tools generate a large portion of
the proof automatically. Programs can be inferred directly from proofs using
the Curry-Howard Correspondence. Interesting discussion here:
[http://www.mail-
archive.com/sc-l@securecoding.org/msg01278.h...](http://www.mail-
archive.com/sc-l@securecoding.org/msg01278.html)

~~~
adrianN
> Also, since they're provably correct the "maintenance" metaphor is no longer
> applicable.

If you want your software to never change, then sure, a proof of correctness
is enough. But I've yet to see a piece of software that is both relevant and
never has to adapt to new requirements.

~~~
verbin217
Agreed. When I said "maintenance" I was referring to the continuous post hoc
work needed to uphold the original functionality as it encounters the full
range of it's potential input.

------
zaroth
One non-fatal point but something to be aware of with this approach; the list
of hidden service addresses isn't itself hidden, and these servers are easy to
fingerprint. So it's trivial to discover the list of all Ricochet identities,
and also know when they are online (so over time perhaps who is talking to
who).

Also, Tor hidden services are not necessarily designed for the case of a
single address coming online and offline repeatedly. I don't think there are
specific known exploits for that case other than the timing issues, but the
other thing that comes to mind is cycling through too many guard nodes over
time.

~~~
FungalRaincloud
This is a good point. The metadata about time online might well be enough to
pinpoint who is talking to who, over a long enough time. One option to avoid
this is to get rid of status indicators, though that is inelegant and means
the message would have to sit on the server at least until it expired. I'm not
too concerned with the messages sitting on the server, because if the message
passes through the server, then they could be storing it either way, and I'm
already trusting that they will do that responsibly. Well, at the very least,
trusting them to do that responsibly as long as there is no algorithm for
faster large prime factorization, and the message is unreadable to them
anyway. Expiration timers could be deliberately very short, which would reduce
server load. I would personally allow the expiration timer to be user-set,
because I believe the average security conscious person is going to want the
timer to be short, unless there is a reason for the message to hang around.

Of course, this doesn't completely address the issue. It would still be
theoretically possible to check for connections to the server, and determine
online/offline status just from whether the messages are going out immediately
after being sent in. Even generating fake data might not be enough to
completely reduce that theoretically possible to the realm of technically
impossible. It's still a risk to keep in mind. You can also never truly rule
out that the service itself is compromised by an entity who wants your (meta
or otherwise) data. You're safest disposing of your identity regularly, to
disconnect previous conversations from new ones, if you're concerned about
metadata analysis, which is considerably less elegant of a solution.

Of course, if your identity is anonymous, you don't truly have to worry about
the metadata analysis, unless the person on the other end is compromised by a
malicious agent, and knows details about you that could deanonymize you....

------
imrehg
I wonder if this design would allow group chat as well, not just p2p?

~~~
jacquesm
I can see a fairly simple extension assuming a friend-of-a-friend style
forwarding. It would be that much slower than one-on-one and participants have
to remain online for the chat not to experience splits.

As soon as the thing needs to work with participants joining/leaving at will
you'd need some kind of supernode or hidden server and that's a vulnerability.

~~~
bentpins
Distributed databases have solved both the problem of splits, and requiring a
fixed master server. MongoDB for example has a master node, but if this leaves
the other nodes will elect a new one. All nodes accept queries and will sync
up over time.

[http://docs.mongodb.org/manual/faq/replica-
sets/](http://docs.mongodb.org/manual/faq/replica-sets/)

------
frantzmiccoli
I have spend a lot of time looking for some cool discussion stuff built over
Tor! It looks like it.

If someone is looking for another address to add just to test this

ricochet:pp7kgrom5nhcox3y

------
aaronsnoswell
Can someone explain how to verify the .asc signature file for this? I'm not
familiar with pgp.

~~~
phaer
You could have just searched for it. The last paragraph of
[https://www.gnupg.org/gph/en/manual/x135.html](https://www.gnupg.org/gph/en/manual/x135.html)
says:

    
    
        gpg --verify doc.sig doc
    

(the difference between .sig and .asc in this case is only that the latter is
plaintext)

------
troismph
Great work, but without mobile app & push notification it's just another IM
over Tor.

~~~
nness
Can you even run it as a mobile application w\ push notifications if it's over
Tor? Wouldn't that require some kind of central server anyway...

~~~
troismph
Sure, push notification needs a central server. But guys, we so badly need a
mobile IM that meets similar security standards as this project. Do it, and
the world will honor you.

Should the central server be the only missing component of a reliable, secure-
paranoid, mobile IM system, I would be happy donating some dollars.

~~~
chrisballinger
Soon I'll be resuming work on a privacy-conscious push server design,
originally intended to enhance the poor user experience of the existing
ChatSecure iOS client (OTR/XMPP/Tor).

The general idea is that you'd fetch tokens from the server that allow people
to send pushes to you, then distribute them to trusted contacts over an secure
channel. Contacts would then be able to send you pushes from any endpoint of
choice. Somewhat less metadata than existing solutions, and an opportunity for
client diversity.

~~~
troismph
Actually I myself cloned ChatSecure iOS, built it, and played it for a while.
It's a nice app with elegant interface yet lacks push notification. If you
plan to improve it, I would be happy to be a beta tester :-)

p.s. So honest is this app to explicitly state that I need to keep it
foreground to receive new message from XMPP server.

------
thrwwy_2015_1_2
I downloaded and ran your precompiled x86-64 binaries .. It kept hanging with
message "May 25 11:52:06.000 [notice] While fetching directory info, no
running dirservers known. Will try again later. (purpose 14)"

It is not usable too. Tried sending request to ricochet:qn6uo4cmsrfv4kzq

It refused to move beyond Request:Pending connection

Man i hate these security software soooo much.

