> From 2019 to 2021, Ricochet was used by the admins (as well as an undercover investigator) of the child porn onion site Boystown. To identify the perpetrators, German police used a correlation analysis attack. By sending Ricochet messages to perpetrators and monitoring several hundred Tor nodes for simultaneous traffic of the correct size, authorities were able to identify intermediate Tor nodes and then also the p…
https://github.com/blueprint-freespeech/ricochet-refresh/iss... Is it not related?
First the good(?) news in bulleted list format:
- As far as we know these efforts took place before the vanguards-lite feature became standard in tor which makes guard discovery of onion-services harder
- The de-anonyimsation efforts took many months if not years and was a targeted effort (i.e. they did not have a turn-key de-anonymise onion-services solution)
- it was only possible because the Germans knew the target's id/onion-service; if the target had kept their id secret then the Germans wouldn't have been able to de-anonymise it.
- we've been working on a solution to the cyber-stalking problem for a few years since it was first discovered; you can find out all about that here: https://gosling.technology/design-doc.xhtml
- work has started on the next major version of Ricochet-Refresh which will include these improvements, so look forward to that in the coming years
---
The linked bug is related but it's not exactly the attack vector believed to be used in the boystown incident. Specifically (according to this artikel linked from wikipedia: https://www.heise.de/en/news/Boystown-investigations-Catchin...), the German police seem to been able to send arbitrary messages to the target which would imply they had compromised one of the target's contacts or the target had accepted a friend request from the police. So in some sense, the Germans had an easier time at it than we hypothesized since they didn't need to rely solely on metadata of online/offline status to find the user's guard. Instead they basically got lucky and were able to fingerprint their own network traffic to the user through relays they happened to control (unknown if they ran their own custom relays or tapped existing).
Sorry it's a bit of hand-wavey here as the reporter refused to give us source documents so we don't actually know precisely how this attack worked and have had to piece things together based on their claims and the state of tor, the tor network, and ricochet-im back then. We've had to basically rely on the word of reporters that they're understanding their material correctly and that they've communicated it correctly (so like a second-hand retelling of a bug report XD). We do know it took the Germans quite a while (i.e. months to years) to do this and had to start over a few times when the target's guard node rotated.
The fundamental problem which makes this sort of attack possible is that onion-service based peer-to-peer communications necessarily require an always-on onion-service for your peers to connect to. Without this piece nothing works. To work around this problem, we've been working on Gosling ( https://github.com/blueprint-freespeech/gosling ) which at a high level, allows you to have the p2p properties without the always on possibly public onion-service by basically negotiating credentials for 'secret' onion-services known only to your authorised peers (i.e. you contacts). Once you've added all your peers/friends that you want, you can shut down the public onion-service without interrupting normal communications with your peers. This of course does imply that you need to trust you contacts aren't cops.
For the specifics, please go read our spec: https://gosling.technology/gosling-spec.xhtml
Anyways, happy to answer any further questions on this.