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

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

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.

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/

Tox connects directly over P2P though, so unlike this it exposes your IP address to everyone on your friends list (possibly even everyone in the world - I haven't looked too closely at how it announces addresses), and allows a passive adversary to easily see who you're talking to and when.

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.

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....

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.

You could have just searched for it. The last paragraph of 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)

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...

Soon?