7 ms·

Ricochet: An encrypted, anonymous IM client built on Tor hidden services

165 points by synchronise 11y ago

sarahj 11y ago
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 11y ago
  Now that you associated this address publicly with your profile on HN you compromised anonymity already.
  - mschuster91 11y ago
    Why? It will still be private who has conversations with whom and especially the content.
    - SoreGums 11y ago
      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 11y ago
        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 11y ago
        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.
    - frevd 11y ago
      Hm true, although everybody knows the identity, nobody can peek into the chats. Good point. That would then allow for generating addresses from speaking aliases, so we don't have to remember GUIDs. Wondering what the current base for the address is, hopefully just some random number persisted on the computer.
      - thefreeman 11y ago
        It's a TOR hidden service address
  - FungalRaincloud 11y ago
    What is compromised is the disconnect from a real persona. There are times where you would like everyone to know they are talking to you, but no one to know who you are talking to, or what is being said. It's like publicly listing a pubkey that is linked to your real identity. You want people to have confidence in who they are talking to, sometimes. This is a valuable chat client even if you publicly announce an address. I'm likely to set one up myself, and announce it, if I like the platform, but I haven't really read into it yet. Of course, if the Tor connection is live, and you are doing anything at all illegal on that connection, your endpoint is now linked to your real identity, so you are not quite as protected as you could be. If you're keeping a chat client like this live, you need to be careful how else you use the connection.
eosrei 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.html http://www.mail-archive.com/sc-l@securecoding.org/msg01278.h...
      - adrianN 11y ago
        > 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.
troismph 11y ago
Great work, but without mobile app & push notification it's just another IM over Tor.
- sturmeh 11y ago
  Soon?
- nness 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
fuckedapanda 11y ago
Fastest way onto the NSA watchlist yet
deleted 11y ago
[deleted]
thrwwy_2015_1_2 11y ago
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.
imrehg 11y ago
I wonder if this design would allow group chat as well, not just p2p?
- jacquesm 11y ago
  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 11y ago
    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/
unicornporn 11y ago
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 11y ago
  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/
tobias2014 11y ago
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 11y ago
  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.
aaronsnoswell 11y ago
Can someone explain how to verify the .asc signature file for this? I'm not familiar with pgp.
- phaer 11y ago
  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)
frantzmiccoli 11y ago
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
zaroth 11y ago
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 11y ago
  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....

165 points by synchronise 11y ago

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 11y ago
Now that you associated this address publicly with your profile on HN you compromised anonymity already.
- mschuster91 11y ago
  Why? It will still be private who has conversations with whom and especially the content.
  - SoreGums 11y ago
    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 11y ago
      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 11y ago
        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.
  - frevd 11y ago
    Hm true, although everybody knows the identity, nobody can peek into the chats. Good point. That would then allow for generating addresses from speaking aliases, so we don't have to remember GUIDs. Wondering what the current base for the address is, hopefully just some random number persisted on the computer.
    - thefreeman 11y ago
      It's a TOR hidden service address
- FungalRaincloud 11y ago
  What is compromised is the disconnect from a real persona. There are times where you would like everyone to know they are talking to you, but no one to know who you are talking to, or what is being said. It's like publicly listing a pubkey that is linked to your real identity. You want people to have confidence in who they are talking to, sometimes. This is a valuable chat client even if you publicly announce an address. I'm likely to set one up myself, and announce it, if I like the platform, but I haven't really read into it yet. Of course, if the Tor connection is live, and you are doing anything at all illegal on that connection, your endpoint is now linked to your real identity, so you are not quite as protected as you could be. If you're keeping a chat client like this live, you need to be careful how else you use the connection.

eosrei 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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.html http://www.mail-archive.com/sc-l@securecoding.org/msg01278.h...
    - adrianN 11y ago
      > 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.

troismph 11y ago

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

sturmeh 11y ago
Soon?
nness 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.

fuckedapanda 11y ago

Fastest way onto the NSA watchlist yet

deleted 11y ago

[deleted]

thrwwy_2015_1_2 11y ago

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.

imrehg 11y ago

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

jacquesm 11y ago
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 11y ago
  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/

unicornporn 11y ago

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 11y ago
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/

tobias2014 11y ago

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 11y ago
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.

aaronsnoswell 11y ago

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

phaer 11y ago
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)

frantzmiccoli 11y ago

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

zaroth 11y ago

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 11y ago
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....