Ricochet-IM: Anonymous, decentralized, metadata-resistant instant messaging(github.com)
github.com
Ricochet-IM: Anonymous, decentralized, metadata-resistant instant messaging
https://github.com/ricochet-im
60 comments
I personally prefer as you said the humble approach - in fact seeing any security software not display a big fat warning is for me a warning.
Telegram has a RCE 0day, not to mention their snake-oil cryptography track record (Diffie-Hellman backdoor).
Ricochet was audited in 2016: https://twitter.com/torproject/status/699668346921332737
And since then things have moved forward only very slowly, but I do not see this as a sign of the project being abandoned more like that there aren't enough people to maintain it.
FWIW the @torproject still endorses ricochet for now: https://twitter.com/torproject/status/1073322441836036096
Ricochet was audited in 2016: https://twitter.com/torproject/status/699668346921332737
And since then things have moved forward only very slowly, but I do not see this as a sign of the project being abandoned more like that there aren't enough people to maintain it.
FWIW the @torproject still endorses ricochet for now: https://twitter.com/torproject/status/1073322441836036096
> Telegram has a RCE 0day
Can you provide more context about this, or somewhere I can read about this please? Very curious.
Can you provide more context about this, or somewhere I can read about this please? Very curious.
I'm not about not RCE 0day but here's some information about Telegram's security problems:
https://gitlab.com/edu4rdshl/blog/raw/master/why-telegram-is...
https://gitlab.com/edu4rdshl/blog/raw/master/why-telegram-is...
That's from several years ago.
May 2017 isn't that long ago.
"However, our survey shows that Telegram has had serious and simple
issues in the protocol (e.g. modified buggy Diffie-Hellman key exchange)
that any knowledgeable security expert could penetrate.
By using the command line interface of Telegram we have been able to
snoop on some of our friends and detect the times when they were conversing
to each other. We believe that this is a serious privacy issue, because it
can be exploited to detect relationships in classroom for example."
You are switching the subject.
This has nothing to do with the security of the protocol.
This has nothing to do with the security of the protocol.
That seems like old Mtproto.
can't sorry, and there are no public discussions on this (for now)
You can't use some claim as an argument and then deny any discussion of it. Especially when your claim is extraordinary.
Who are you and why are you spreading this fud?
Everytime instant messaging gets talked about here someone has to bring up how unsecure telegram is. Like someone doesn't want people to use telegram...
Unless you can show me a proof of concept, stop already.
Everytime instant messaging gets talked about here someone has to bring up how unsecure telegram is. Like someone doesn't want people to use telegram...
Unless you can show me a proof of concept, stop already.
> why are you spreading this fud?
a bit rich from a dweeb that retweets Wikileaks conspiracy theories don't you think?
a bit rich from a dweeb that retweets Wikileaks conspiracy theories don't you think?
This is against the guidelines of HN: https://news.ycombinator.com/newsguidelines.html
Please consider disclosing the issue responsibly by releasing it to the public. Keeping it secret and only telling a select few gives the ability to the said few (which may include Telegram itself) to use the vulnerability maliciously. In addition even if you have disclosed the issue to the Telegram team and Telegram has fixed said vulnerability the same may not be said for any forks of it whose maintainers are not aware of the issue.
> and only telling a select few gives the ability
If more than 1 person knows something it's no longer a secret. Likewise if 2 people know about the existence of a 0day it's no longer a 0day.
...
Why should I burn a 0day? Who will pay me for it? I'm not stupid and I don't participate in the responsible disclosure circle jerk.
TG is snakeoil: If you use it for anything more serious than hiding an affair from your spouse high chance you get burnt. Especially wanna be terrorists ought to stay clear.
TG is one giant weird machine: You'll notice quickly if you play with it. There very likely many 0days in TG and for sure LE has access to it too. So finding something isn't even a statistical outlier.
People who think that responsible disclosure must be practiced are just parroting the corporate bullshit. Bug bounties hunters are the Uber drivers of InfoSec. Poor fuckers that are pressed into a system that only benefits the corporate overlords. How about starting with responsible QA instead of moving fast & breaking things?
If more than 1 person knows something it's no longer a secret. Likewise if 2 people know about the existence of a 0day it's no longer a 0day.
...
Why should I burn a 0day? Who will pay me for it? I'm not stupid and I don't participate in the responsible disclosure circle jerk.
TG is snakeoil: If you use it for anything more serious than hiding an affair from your spouse high chance you get burnt. Especially wanna be terrorists ought to stay clear.
TG is one giant weird machine: You'll notice quickly if you play with it. There very likely many 0days in TG and for sure LE has access to it too. So finding something isn't even a statistical outlier.
People who think that responsible disclosure must be practiced are just parroting the corporate bullshit. Bug bounties hunters are the Uber drivers of InfoSec. Poor fuckers that are pressed into a system that only benefits the corporate overlords. How about starting with responsible QA instead of moving fast & breaking things?
Sorry to call you out, we should always assume good faith from HN commenters but I must say that this is childish behaviour.
Either it's pertinent information to be entered into the public record as part of your comment, or it's not.
If it's pertinent information you don't get to say "trust me", you have the responsibility to provide information.
If you cannot do that, then do not say it. You will not convince me with mealy mouthed weasel words.
--
On a more personal note: this comment sounds like the kind of thing I would see on skiddie hacker forums 15 years ago. Please conduct yourself better.
Either it's pertinent information to be entered into the public record as part of your comment, or it's not.
If it's pertinent information you don't get to say "trust me", you have the responsibility to provide information.
If you cannot do that, then do not say it. You will not convince me with mealy mouthed weasel words.
--
On a more personal note: this comment sounds like the kind of thing I would see on skiddie hacker forums 15 years ago. Please conduct yourself better.
> People who think that responsible disclosure must be practiced are just parroting the corporate bullshit
I did not use "responsible disclosure" as commonly defined (apologies for any confusion), simply because I do not think that telling only the creator of the program is responsible - instead I asked you to try and consider disclosing the issue responsibly by making it public to everyone (rather than just Telegram). I consider a disclosure responsible only if both the users and any developers (including these of any forks) are aware of the issue at the same time. I do not think that the way that I personally used the term "responsible" is in any way "corporate bullshit", after all the corporations tend to ask to be the only ones (or the first ones) to learn about the issue.
I did not use "responsible disclosure" as commonly defined (apologies for any confusion), simply because I do not think that telling only the creator of the program is responsible - instead I asked you to try and consider disclosing the issue responsibly by making it public to everyone (rather than just Telegram). I consider a disclosure responsible only if both the users and any developers (including these of any forks) are aware of the issue at the same time. I do not think that the way that I personally used the term "responsible" is in any way "corporate bullshit", after all the corporations tend to ask to be the only ones (or the first ones) to learn about the issue.
So you don't have a 0day. Normally people don't brag about it, because it only lures attention. And now by your own definition, many people know about the (potential?) 0day, even without details.
Given that it was mentioned off-hand and you’re unable (or unwilling) to give more information, why would I consider this anything other than FUD?
Please substantiate your claim or don’t make it.
Please substantiate your claim or don’t make it.
I don't think that's the same Ricochet? @Ricochet on Twitter is associated with Ricochet dot com, "the leading place for civil discussion of the center-right and beyond." It requires paid membership.
(Though perhaps @torproject meant to link to this Ricochet IM product and not @Ricochet...?)
(Though perhaps @torproject meant to link to this Ricochet IM product and not @Ricochet...?)
For avoidance of doubt: it is Ricochet IM that was security audited: https://www.nccgroup.trust/us/our-research/ricochet-security...
But yes looks like the tweet is @ the wrong account.
But yes looks like the tweet is @ the wrong account.
oh dear :D ... well spotted! that's most certainly not an endorsement for the former and was supposed to point to the ricochet IM. (facepalm) :)
I'm building something similar using Tor, but using v3 addresses. As v3 is now the default and recommended onion version, will this project move to them? The address are much larger and more unwieldy. However, I've found publishing ephemeral v3 services to be much faster (i.e. a couple of seconds vs a minute). Also since it's basically the ed25519 pub key, the address is enough to be able to verify signed content.
I believe cwtch[0] is essentially Ricochet, but with support for group chats and v3 addresses.
[0] https://cwtch.im/
[0] https://cwtch.im/
Yup, saw them, they had even looked at using my Tor Go controller lib. I look forward to watching it develop towards end user friendliness. I am a fan of the project.
So my security knowledge is a bit lacking. Is there anything that would make using cwtch less secure than using Riochet by itself?
Just potential vulnerabilities in the implementation AFAIK.
Cwtch hasn't been audited whereas Ricochet has.
Cwtch hasn't been audited whereas Ricochet has.
Tor can also be de-anonymized if a person controls a significant chunk of the network. However, if we keep changing the route constantly, (instead of establishing a static route during startup time and just reusing it, as tor does), we might make a much better and safer system. As you can expect, creating route takes time and defeats the purpose of IM.
Tor changes routes every 10 minutes.
Consider adding forward-secrecy and encrypting the payloads (beyond the Tor transport) as Richochet does neither.
> Consider adding forward-secrecy
Considering. But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point. Forward secrecy for the data at rest (i.e. in the DB) could have value but my current on-disk DB doesn't support this. But on the wire assumes MITM which should not be the case for user-to-onion. There is some defense in depth, but it's not something I'll target for MVP. There will be a built in data-expiration feature.
> and encrypting the payload
What does encrypting the payload help with when talking to an onion is already E2E encrypted? I do plan on encrypting at rest, but not in transit at least not at first. Could move to do TLS, but I'd be doubling Tor efforts because I'd probably just encrypt+sign w/ that same ed25519, so there'd be no real value.
Considering. But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point. Forward secrecy for the data at rest (i.e. in the DB) could have value but my current on-disk DB doesn't support this. But on the wire assumes MITM which should not be the case for user-to-onion. There is some defense in depth, but it's not something I'll target for MVP. There will be a built in data-expiration feature.
> and encrypting the payload
What does encrypting the payload help with when talking to an onion is already E2E encrypted? I do plan on encrypting at rest, but not in transit at least not at first. Could move to do TLS, but I'd be doubling Tor efforts because I'd probably just encrypt+sign w/ that same ed25519, so there'd be no real value.
> "But since it is user-to-user, you can only trust the user to store it how they want since they are gonna see it in the clear at some point."
That's a problem with almost every messaging system. I wouldn't worry about that.
> "What does encrypting the payload help with when talking to an onion is already E2E encrypted?"
It would be a requirement of PFS, but I meant encrypt at rest - my mistake.
That's a problem with almost every messaging system. I wouldn't worry about that.
> "What does encrypting the payload help with when talking to an onion is already E2E encrypted?"
It would be a requirement of PFS, but I meant encrypt at rest - my mistake.
Have you published to git? I have been wanting to try Ricochet but its inactive state makes me nervous.
In very early stages (like too early to know what's going on or why I'm taking certain approaches). However, I have built a couple libraries I leverage. There is a Tor embedder/controller [0] (with a project assisting with statically linked Tor [1]) and there is a Go wrapper for locally encrypted Sqlite [2] (which I need to update). That Tor controller even has a gRPC example that shows the basic idea of starting an onion service and communicating over Tor.
0 - https://github.com/cretz/bine
1 - https://github.com/cretz/tor-static
2 - https://github.com/cretz/go-sqleet
0 - https://github.com/cretz/bine
1 - https://github.com/cretz/tor-static
2 - https://github.com/cretz/go-sqleet
Thanks for the links. I will check it out. Recently I created a hidden service using whonix but didn't get a chance to build the site itself. actually created a couple different types so I have a little, very little, experience in the creation and utilization of H.S. but I look forward to looking at your idea and work. The concept is something that has a lot of positive possibilities.
Briar project is doing something similar. https://briarproject.org/
Actively developed
Actively developed
The design doc is here. https://github.com/ricochet-im/ricochet/blob/master/doc/desi...
It describes one of its goals as, "Resist blacklisting or denial of service against users."
Preventing both blacklisting and DoS seems contradictory to me in an anonymous messaging protocol. If an anonymous party wants to spam me to make the product effectively unusable, I either need to be able to blacklist them, or to whitelist known contacts, in which case none of them are anonymous.
It describes one of its goals as, "Resist blacklisting or denial of service against users."
Preventing both blacklisting and DoS seems contradictory to me in an anonymous messaging protocol. If an anonymous party wants to spam me to make the product effectively unusable, I either need to be able to blacklist them, or to whitelist known contacts, in which case none of them are anonymous.
It means there's no third party (including Ricochet devs!) that can blacklist users.
You can easily delete contacts you don't want to receive messages from -- and in fact the UI is lacking in this regard: if you delete someone and subsequently change your mind, the only way to fix this is to edit the config file manually and remove them from the list of blocked contacts.
Source: am a very happy Ricochet user.
You can easily delete contacts you don't want to receive messages from -- and in fact the UI is lacking in this regard: if you delete someone and subsequently change your mind, the only way to fix this is to edit the config file manually and remove them from the list of blocked contacts.
Source: am a very happy Ricochet user.
But the anonymous user can create N anonymous accounts and spam you N times with N accounts, right?
That's where spam forces us to choose between blacklisting people and whitelisting (which breaks anonymity).
That's where spam forces us to choose between blacklisting people and whitelisting (which breaks anonymity).
I'd never accept a request from a random user. My workflow would be like this: agree to discuss on signal or via pgp, which you use to get the ricochet-ID from the person that intends to connect with you. Once they tell you their id via this out of band channel, it's easy to reject any other requests that you don't expect. My ricochet-id is public knowledge now.
But say you're a journalist who wants to protect their source (on your end) e.g. a total stranger who is going to tell you some secrets then no need to even have a contact list. No need for a history. You just use the ricochet-id once. Maybe in a short-lived VM, Qubes or Tails whatever ... And tear down the whole system anyway once I'm done with the chat.
So in the first case you can simply avoid spam with boostrapping a safe rendezvous point, the second case would never see any spam.
But say you're a journalist who wants to protect their source (on your end) e.g. a total stranger who is going to tell you some secrets then no need to even have a contact list. No need for a history. You just use the ricochet-id once. Maybe in a short-lived VM, Qubes or Tails whatever ... And tear down the whole system anyway once I'm done with the chat.
So in the first case you can simply avoid spam with boostrapping a safe rendezvous point, the second case would never see any spam.
I deliberately publish my Ricochet ID (ricochet:it2j3z6t6ksumpzd) and accept most requests from random people. It's led to mostly people who add me as a contact then close Ricochet before I reply and never open it again, a large handful of fun conversations with interesting people, and a couple of weird conversations with crazy people :).
Sadly not scalable, but one of the great pleasures of using early or obscure communications media.
The entire early Internet worked this way and it was lovely.
The entire early Internet worked this way and it was lovely.
If you'd never accept a request from a random user, then you're not doing anonymous messaging.
If you're a journalist who wants to receive a message from a total stranger, then you'd have to accept a contact request from a that stranger. Spammers can then deny the journalist access to anonymous requests by spamming them with anonymous requests.
The journalist could try to keep their contact ID a secret, but then anonymous sources would have no idea how to contact the journalist.
If you're a journalist who wants to receive a message from a total stranger, then you'd have to accept a contact request from a that stranger. Spammers can then deny the journalist access to anonymous requests by spamming them with anonymous requests.
The journalist could try to keep their contact ID a secret, but then anonymous sources would have no idea how to contact the journalist.
Terminology is the single biggest problem here: "Anonymous communication" in CS does NOT mean you do not reveal your identity to the person you are communicating with. It means you stay anonymous from the network perspective: No third party learns with whom you are communicating, and everything you reveal to your communication partner becomes an explicit attribute: Your "identity"/name/nickname, but also your location.
>If you'd never accept a request from a random user, then you're not doing anonymous messaging.
as mentioned you can use other anonymous channels before you switch to another one such as ricochet. the point isn't to establish authenticity before moving to anonymity but to add a layer of protection that allows you to decide on the rendezvous point and further increase plausible deniability
as mentioned you can use other anonymous channels before you switch to another one such as ricochet. the point isn't to establish authenticity before moving to anonymity but to add a layer of protection that allows you to decide on the rendezvous point and further increase plausible deniability
Sure, then you'd get N contact requests which you'd have to ignore (which has the same effect as deleting a contact which you'd previously accepted).
But people can spam your email account as well. When this became a problem, spam filters were developed. There's no reason the same thing couldn't happen in Ricochet if spam became a problem.
Ricochet's problem isn't that too many spammers are using it. It's that almost nobody at all is using it.
But people can spam your email account as well. When this became a problem, spam filters were developed. There's no reason the same thing couldn't happen in Ricochet if spam became a problem.
Ricochet's problem isn't that too many spammers are using it. It's that almost nobody at all is using it.
Email spam filters didn't/don't actually work that well without de-anonymizing features like SPF and DKIM.
I'm not saying that spam is a problem today, but that the design goals of Richochet don't allow it to deal with the spam problem for users who actually want anonymous messaging.
I'm not saying that spam is a problem today, but that the design goals of Richochet don't allow it to deal with the spam problem for users who actually want anonymous messaging.
What anonymous messaging system would you recommend?
A possibility to blacklist users is essential for a messaging service to be able to respond to abuse requests. I wonder how Ricochet plans to handle it.
Ricochet isn't a "service". It's a peer-to-peer protocol.
There is nobody to send abuse complaints to, by design, and therefore no requirement to be able to respond to them.
There is nobody to send abuse complaints to, by design, and therefore no requirement to be able to respond to them.
Right, it’s a protocol with a reference implementation.
It would just be nice to have a service with the kind of privacy properties this software provides on a mobile device where software distribution is very centralized and requires a tiny bit of censorship compliance.
Project seems inactive, last commit on github in mid-2017. Is there any special reason this was posted?
I think it's in reaction to Show HN: Whapp-irc – A simple WhatsApp IRC gateway (github.com) https://news.ycombinator.com/item?id=18897347
I think there's a pattern that an open source alternative or lookalike project gets posted when a proprietary one (or linked to a non-opensource one) hits the front page.
I think there's a pattern that an open source alternative or lookalike project gets posted when a proprietary one (or linked to a non-opensource one) hits the front page.
I shared it because I've been messing around with ricochet this weekend. I did look at the sources and couldn't find anything that I hated. Some problems exist in the latest debian package (in sid) related to the AppArmor configuration ... (see my issue I created in their github). So this is how I ended up posting it ... I wasn't aware of this other WhatsApp post. WhatsApp is snakeoil imo.
Though you're probably right about the tendency of people to share related things. Not just when a non FOSS project gets posted on HN but in general people remember similar things and then post it. See the comment here on briar, which is a promising project too. But it serves a different use-case - I want a non mobile solution I can run on FOSS system with FOSS hardware TL;DR: I no longer use phones in the traditional sense - only burner phones for 2FA without apps and not for making calls ... Ricochet delivers that because I can launch it via a Debian, Tails[1], QubesOS whatever ... :)
[1] requires a little fuckery but not too bad: https://incoherency.co.uk/blog/stories/ricochet-tails.html
Though you're probably right about the tendency of people to share related things. Not just when a non FOSS project gets posted on HN but in general people remember similar things and then post it. See the comment here on briar, which is a promising project too. But it serves a different use-case - I want a non mobile solution I can run on FOSS system with FOSS hardware TL;DR: I no longer use phones in the traditional sense - only burner phones for 2FA without apps and not for making calls ... Ricochet delivers that because I can launch it via a Debian, Tails[1], QubesOS whatever ... :)
[1] requires a little fuckery but not too bad: https://incoherency.co.uk/blog/stories/ricochet-tails.html
I hope open source IM focus more on client usability & UX. Many of the feature centric programs are simply too ugly to use.
This is an interesting line from the github readme. And I applaud for being humble. This is something which seemed lacking when I read about dapps (etherium) -- people rarely talked about having low trust on contracts written by somebody else.