#2384 closed defect (fixed)

anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2p

Reported by: dawuud Owned by: warner
Priority: normal Milestone: 1.12.0
Component: code-network Version: 1.10.0
Keywords: anonymity tor Cc:
Launchpad Bug:

Description

I believe it was Leif Ryge who first pointed this out... We really need to randomize the client ID when using an anonymity network like Tor or I2p.

This ticket is definitely related to #517 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517

This ticket also seems to be a sub-ticket of #1010 https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010 in so far as we can turn this client ID randomization on and off with a configuration option.

Change History (10)

comment:1 Changed at 2015-02-10T18:26:35Z by zooko

  • Summary changed from anonymize client IDs when using Tahoe-LAFS with anonymity net like Tor or I2p to anonymize Tub IDs when using Tahoe-LAFS with anonymity net like Tor or I2p

comment:2 follow-up: Changed at 2015-02-10T18:56:28Z by zooko

Brian pointed out in Nuts & Bolts today that #510 would solve this.

comment:3 in reply to: ↑ 2 ; follow-up: Changed at 2015-02-10T18:57:43Z by zooko

Replying to zooko:

Brian pointed out in Nuts & Bolts today that #510 would solve this.

Or maybe it was Daira who pointed that out.

comment:4 in reply to: ↑ 3 Changed at 2015-02-11T16:25:14Z by daira

Replying to zooko:

Replying to zooko:

Brian pointed out in Nuts & Bolts today that #510 would solve this.

Or maybe it was Daira who pointed that out.

It was. (More precisely, that an HTTP-based protocol wouldn't have this specific problem with client tub IDs, although that isn't the only problem involved in client anonymisation.)

Last edited at 2015-02-11T16:27:52Z by daira (previous) (diff)

comment:5 Changed at 2016-08-29T23:30:17Z by warner

Current status: client connections to storage servers use ephemeral Tubs (thanks to #2759), so storage servers won't see tub-id correlations between subsequent boots of a single client.

The IntroducerClient, though, uses a static tub (with key stored in NODEDIR/private/node.pem) for all connections. So the Introducer can correlate connections across client reboots.

Do folks think we can close this ticket as is, or should we use an ephemeral Tub for the introducer client too?

(note that when Accounting happens, clients will get a persistent Ed25519 public key, and they'll sign their storage-server messages with it. But I think we can just declare that when anonymous=true, these keys are disabled, or regenerated at each boot, and you don't get to participate in any accounting-related tasks. Maybe we can add a pseudonymous=true flag which will allow persistent client pubkeys, but still enforce the other safety restrictions. In that world, servers could tell which clients were which, but that "identity" is still unlinked to the client's real IP address)

comment:6 Changed at 2016-08-29T23:30:47Z by warner

  • Component changed from unknown to code-network
  • Keywords anonymity tor added
  • Milestone changed from undecided to 1.12.0

comment:7 Changed at 2016-09-06T19:27:58Z by warner

In today's devchat, we decided to document the !TubID linkages that clients currently reveal (introducer client + storage server, and multiple connections within a single client lifetime for everything else), and then close this ticket. We'll add a new ticket (with milestone=undecided) for either addressing the remaining linkages, or WONTFIXing them.

Version 0, edited at 2016-09-06T19:27:58Z by warner (next)

comment:8 Changed at 2016-09-06T19:29:16Z by warner

  • Owner set to warner
  • Status changed from new to assigned

comment:9 Changed at 2016-09-13T09:22:47Z by warner

#2828 added for addressing/accepting the remaining linkages.

comment:10 Changed at 2016-09-13T09:23:12Z by Brian Warner <warner@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 80acd56/trunk:

docs: describe known linkability

closes ticket:2384

Note: See TracTickets for help on using tickets.