this post was submitted on 04 Jun 2024
6 points (65.0% liked)

Monero

1666 readers
33 users here now

This is the lemmy community of Monero (XMR), a secure, private, untraceable currency that is open-source and freely available to all.

GitHub

StackExchange

Twitter

Wallets

Desktop (CLI, GUI)

Desktop (Feather)

Mac & Linux (Cake Wallet)

Web (MyMonero)

Android (Monerujo)

Android (MyMonero)

Android (Cake Wallet) / (Monero.com)

Android (Stack Wallet)

iOS (MyMonero)

iOS (Cake Wallet) / (Monero.com)

iOS (Stack Wallet)

iOS (Edge Wallet)

Instance tags for discoverability:

Monero, XMR, crypto, cryptocurrency

founded 1 year ago
MODERATORS
 

Academic paper from last month's International World Wide Web Conference for people who enjoy reading such things. :-)

*"Our approach involves injecting malicious Monero Tor hidden service nodes into the Monero P2P network to correlate the onion addresses of incoming Monero Tor hidden service peers with their originating transactions.

And by sending a signal watermark embedded with the onion address to the Tor circuit, we establish a correlation between the onion address and IP address of a Monero Tor hidden service node."*

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 10 points 5 months ago (6 children)

Deanonymizing Transactions Originating from Monero Tor Hidden Service Nodes

That is the actual title of the paper, which is very different to what OPs implies.

[–] [email protected] 5 points 5 months ago (5 children)

also the attack requires a very large % of both monero nodes communicating with tor and also tor nodes themselves. unless there is something im not understanding. i read the paper for a while, that's what it seemed to me

[–] [email protected] 4 points 5 months ago (2 children)

In the Tor community we are considering how much a relay operator can have in total and where we draw the line. NTH currently has almost 20% exit traffic and we (5 orgs in an AS) have a bit more. https://nusenu.github.io/OrNetStats/

[–] [email protected] 3 points 5 months ago (1 children)

looks like 20% of guards are run on Hetzner gear. this is really bad considering they are knowm to be backdoored by feds. yet somehow everyone forgot, like they always do. sad shit.

[–] [email protected] 3 points 5 months ago* (last edited 5 months ago) (1 children)

Yes, for years we in the Tor community have been trying to point out this to new relay operators: https://community.torproject.org/relay/technical-considerations/ Try to avoid the following hosters:

  • OVH SAS (AS16276)
  • Online S.a.s. (AS12876)
  • Hetzner Online GmbH (AS24940)
  • DigitalOcean, LLC (AS14061)
  • Frantech/BuyVM (AS53667) is also often full, because Francisco allows exits and he takes care of the abuse mail shit.

Guards, bridges and middle relays can actually be operated at nearly any hoster. They don't get abuse and don't attract attention. It's difficult to find a hoster for an exit. It's best to have your own AS.

[–] [email protected] 5 points 5 months ago

thanks for the additional info.

tor project needs to make a big announcement or something, because basically you can consider these nodes as being run by the fucking NSA/5eyes. this is really bad. one of the reasons i dont trust TOR alone for certain things anymore.

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago)

interesting stuff, thanks for the info.

also did you see this in the paper?

In Timed Sync Response messages from a Tor client node to its outgoing hidden service peers, the last address in peer list is certainly different between different Timed Sync Response messages because only unshared onion addresses are sent. On the other hand, all Timed Sync Response messages from a Tor hidden service node to its outgoing hidden service peers have the same the last onion address in peer list, which is always its own onion address. Therefore, the repetition of the last address of Timed Sync Response messages from a Monero Tor hidden service node to its outgoing Monero Tor hidden service peers can be exploited by an attacker to identify incoming Monero Tor hidden service peers from incoming Monero Tor client peers and obtain its onion address.

is this a bug or a feature? have you spoken to anyone in the tor community about this? is there a going to be a mitigation for this? this seems concerning, yet I've seen no one talk about, which is even more concerning.

Edit: my bad, I forgot this is a Monero thing lol, not a TOR node thing

load more comments (2 replies)
load more comments (2 replies)