On 27 Feb 2017, at 23:48, nusenu nusenu@openmailbox.org wrote:

This group is still growing.

Note that the following table is _not_ sorted by FP.

The FP links these relays even across ISP, and given the FP column pattern it might be obvious what they are after.

They do not have the hsdir flag yet.

https://raw.githubusercontent.com/nusenu/tor-network-observations/master/201...

Is there a tool out there that tells me which HSDir is/will probably be responsible for a given onion address (and at what time)?

There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)

In short, it's the first 3 fingerprints following descriptor-id:

permanent-id = H(public-key)[:10] descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica)) where H is SHA1.

The spec is: https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n222 https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n505

The implementation is: https://gitweb.torproject.org/tor.git/tree/src/or/rendcommon.c#n127

As an aside, this attack is not possible with next-generation hidden services, because the HSDir identities are hashed with the daily shared random value: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...

T

-- Tim Wilson-Brown (teor)

teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

nusenu:

...

...

Is there a tool out there that tells me which HSDir is/will probably be responsible for a given onion address (and at what time)?

There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)

I probably was not very clear in my question. I'm not aiming for the reverse path, just the normal calculation a tor client does given an onion address but instead of just calculating the current descriptor-id, print descriptor-ids for the future N days for onion address M (for the pre-prop224 world).

For the "current-only" case you might use stem: https://gist.github.com/nusenu/8339cfd5351b64c47676241a40ee2942

Ivan Markin:

On Tue, Feb 28, 2017 at 02:09:00AM +0000, nusenu wrote:

...

...

...

Is there a tool out there that tells me which HSDir is/will probably be responsible for a given onion address (and at what time)?

There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)

I probably was not very clear in my question. I'm not aiming for the reverse path, just the normal calculation a tor client does given an onion address but instead of just calculating the current descriptor-id, print descriptor-ids for the future N days for onion address M (for the pre-prop224 world).

FYI https://gist.github.com/nogoegst/895dde228496e04f409fc6d160a5de5a

$ go run onion-desc-advance.go -time 1488288001 yrcfcqhja2ide7yh

prints descriptor IDs for the given time for replica #1 and #2.

Thanks for this.

Shouldn't the first 2 or 3 hex digits of your output (after converting them to hex) without time option and the actual intro point FPs match when run at roughly the same time?

example for duckduckgo:

./get-intro-points.py 3g2upl4pq6kufc4m [1] 3g2upl4pq6kufc4m:56782537778BEFC5A48080B58BE01E814AF9B5D3 3g2upl4pq6kufc4m:769DBA4C0C992FCEA080618833FD7BF5AC1F4F41 3g2upl4pq6kufc4m:744B753C7F5E0C6BDD240EE5D879A36C650D2B00

go run descriptor-id-calc.go 3g2upl4pq6kufc4m replica #0: sv5uuknuqvjgquf4hu4m6tvcyuyiyvw7 -> hex: 957B4A29B485526850BC3D38CF4EA2C5308C56DF

replica #1: crpc4lkarusgflm5nblslpopg5qpvw7i -> hex: 145E2E2D408D2462AD9D685725BDCF3760FADBE8

they start with 95.. and 14.. but the actual intro points start with 56.., 76.. and 74.. ?

thanks

[1] https://gist.github.com/nusenu/8339cfd5351b64c47676241a40ee2942

On Thu, Mar 02, 2017 at 01:11:00PM +0000, nusenu wrote:

nusenu:

...

Shouldn't the first 2 or 3 hex digits of your output (after converting them to hex) without time option and the actual intro point FPs match when run at roughly the same time?

example for duckduckgo:

./get-intro-points.py 3g2upl4pq6kufc4m [1] 3g2upl4pq6kufc4m:56782537778BEFC5A48080B58BE01E814AF9B5D3 3g2upl4pq6kufc4m:769DBA4C0C992FCEA080618833FD7BF5AC1F4F41 3g2upl4pq6kufc4m:744B753C7F5E0C6BDD240EE5D879A36C650D2B00

go run descriptor-id-calc.go 3g2upl4pq6kufc4m replica #0: sv5uuknuqvjgquf4hu4m6tvcyuyiyvw7 -> hex: 957B4A29B485526850BC3D38CF4EA2C5308C56DF

replica #1: crpc4lkarusgflm5nblslpopg5qpvw7i -> hex: 145E2E2D408D2462AD9D685725BDCF3760FADBE8

they start with 95.. and 14.. but the actual intro points start with 56.., 76.. and 74.. ?

I probably misunderstood how the design works.

The introduction points are not chosen by calculating the descriptor-id and finding the 3 HSDirs next to it (by sorted fingerprint).

tldr: HSDir != IntroPoint.

Introduction points are chosen by random by an onion service and unknown in advance. What is known in advance is only the onion address. Descriptor ID determines which HSDirs are responsible for storing corresponding descriptor. List of the current IntroPoints are embedded into descriptor (that's the reason we have descriptor thing in the first place).

-- Ivan Markin

nusenu:

This group is still growing.

Note that the following table is _not_ sorted by FP.

The FP links these relays even across ISP, and given the FP column pattern it might be obvious what they are after.

They do not have the hsdir flag yet.

https://raw.githubusercontent.com/nusenu/tor-network-observations/master/201...

Nusenu, thank you for reporting these relay. They are now in the process of being removed from the network.

I really appreciate the careful attention that you pay to the Tor network. Many thanks for keeping users safe.

Is there a tool out there that tells me which HSDir is/will probably be responsible for a given onion address (and at what time)?

thanks, nusenu

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On 28 Feb (02:09:00), nusenu wrote:

Donncha O'Cearbhaill:

...

nusenu:

...

This group is still growing.

Note that the following table is _not_ sorted by FP.

The FP links these relays even across ISP, and given the FP column pattern it might be obvious what they are after.

They do not have the hsdir flag yet.

https://raw.githubusercontent.com/nusenu/tor-network-observations/master/201...

Nusenu, thank you for reporting these relay. They are now in the process of being removed from the network.

Thanks for letting us know.

It would be nice if you could share:

Hello!

I'll try to help out as much as I can here.

• if you reached out to the operator (via abuse contacts)

We do that if a valid contact address is present. In this case, we had only one I believe and still no response. Email was sent yesterday ~afternoon EST.

• removal reason

Proximity of fingerprint indicates a clear attempt at insertion in the hashring for an (some) onion address. We are *always* better safe than sorry with bad relays so even without a 100% confirmation, we go ahead.

• what was removed

That, we don't disclose for obvious reasons that if the attackers can see what we removed and when, it makes it easier for them to just adapt in time. Only subscribers to bad-relays@ can know this.

However, those reject/badexit entries at the directory authority level expire after a time period and when they do, they become public here in this DocTor script that monitors any relay that we've expired and will be there for a 6 months period:

https://gitweb.torproject.org/doctor.git/tree/data/tracked_relays.cfg

After that 6 months, you can find commit like this that removes a bunch of them:

https://gitweb.torproject.org/doctor.git/commit/data?id=f89e3dca452a0d776eed...

• method (by FP, IP, IP-range, ...)

We always reject both FP and IP. Sometimes, it can be a full network range. Depends on the attack.

• how long they will be blacklisted

The standard time period is 90 days *but* it's still a human that does that so it goes beyond that time period sometimes. *HUGE* network block though, we are more careful at not extending too much the reject time.

• time of removal

We don't disclose that for now. Only subscribers to bad-relays@ can know this.

There has been *MANY* discussions about having this reject list public and everything in the open. I believe it wasn't full agreement in the end but for now it went towards keeping it close.

Thanks! David

thanks, nusenu

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays