Re: [tor-bugs] #19317 [Metrics/CollecTor]: Sanitize TCP ports in bridge descriptors

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#19317: Sanitize TCP ports in bridge descriptors
-------------------------------+------------------------------
 Reporter:  karsten            |          Owner:
     Type:  enhancement        |         Status:  needs_review
 Priority:  Medium             |      Milestone:
Component:  Metrics/CollecTor  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:                     |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+------------------------------

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Replying to [comment:5 karsten]:
 > > .... `H(...)[:2] / 2^2 + 2^15 + 2^15`.
 > should be `2^15 + 2^14` as it is in both html and java code.

 Uhm, yes!

 > The latter might be more readable when using java7 features, i.e.
 >
 > {{{
 > #!java
 > int hashedPort =
 >  ((((hashInput[0] & 0b1111_1111) << 8) | (hashInput[1] & 0b1111_1111))
 >> 2)
 >       | 0b1100_0000_0000_0000;
 > }}}

 Neat, didn't know about that.  I'll change that as soon as we agree that
 the calculation even makes sense.

 > How much privacy is actually gained with all this?
 > Reducing the range gives some privacy, but how much given that the
 original ports are not randomly distributed in their range?
 > Just point me to an appropriate doc, if this question seems trivial.

 This doesn't add much privacy, it's mostly a way to avoid that we obtain a
 result of 0.  We could have taken different approaches, e.g. `|
 0b0000_0000_0000_0001` or `| 0b1000_0000_0000_0000` or `% (2^16 - 1) + 1`.
 But similar to how we're sanitizing IPv4 addresses to 10.x.x.x rather than
 x.x.x.x, I thought we could sanitize TCP ports to just 49152 to 65535
 which happen to be reserved.  That avoids confusions like a port below
 1024 which might show up in Atlas and confuse bridge operators.  And I
 thought it's better to take the first 14 bits of the hash output rather
 than bits 2 to 16, therefore the `/ 2^2`.  But really, the main goal is
 not to obtain a 0 as result.  And reducing the range of possible ports to
 1/4 doesn't seem like a big issue to me.  Hope this makes sense.  Open to
 alternatives that make even more sense!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19317#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs