Ricochet-IM: Anonymous, decentralized, metadata-resistant instant messaging
github.com
github.com
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.
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
(Though perhaps @torproject meant to link to this Ricochet IM product and not @Ricochet...?)
But yes looks like the tweet is @ the wrong account.
Can you provide more context about this, or somewhere I can read about this please? Very curious.
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?
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.
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.
Please substantiate your claim or don’t make it.
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.
a bit rich from a dweeb that retweets Wikileaks conspiracy theories don't you think?
https://gitlab.com/edu4rdshl/blog/raw/master/why-telegram-is...
"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."
This has nothing to do with the security of the protocol.
0 - https://github.com/cretz/bine
Cwtch hasn't been audited whereas Ricochet has.
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.
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.
Actively developed
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.
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.
That's where spam forces us to choose between blacklisting people and whitelisting (which breaks anonymity).
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.
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.
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.
The entire early Internet worked this way and it was lovely.
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.
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
There is nobody to send abuse complaints to, by design, and therefore no requirement to be able to respond to them.
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.
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