Opened 16 months ago

Last modified 11 months ago

#30092 needs_revision enhancement

Add a probability-to-apply field for circuitpadidng machines

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: wtf-pad, tor-relay, tor-cell, padding, circpad-researchers-maybe-want
Cc: Actual Points: 0.5
Parent ID: Points: 2
Reviewer: asn Sponsor: Sponsor2-can


In #28634, we realized that we may want to make some fraction of pre-built GENERAL and HS_VANGUARDS circuits look like padded onion service circuits, as a defense in depth against a classifier that can still recognize our specially padded onion service circuits as, well, special, and still interesting.

But we don't want to make all general circuits look this way. Just some fraction. So it would be nice if the machine conditions could somehow toss a coin to decide to apply the machine to a circuit. Unfortunately, right now the conditions are memoryless, so we have nothing that can say "you already tossed the coin", but we could special case just this to have a flag on the circuit or something.

Child Tickets

Change History (11)

comment:1 Changed 16 months ago by mikeperry

Actual Points: 0.5
Status: newneeds_review

This was easy, but I'm not sure how best to test it. Open to suggestions if we feel it is necessary to test.

comment:2 Changed 16 months ago by nickm

Milestone: Tor: 0.4.1.x-final

comment:3 Changed 16 months ago by mikeperry

Parent ID: #28634

comment:4 Changed 16 months ago by asn

Reviewer: asn

comment:5 Changed 16 months ago by asn

OK this LGTM.

I think a test would be nice tho since it has grown to non-trivial complexity after the last commit. Here is an easy way to test this:

  • Put the body of if (machine->conditions.apply_with_probability > 0) { into its own function which is gonna be unittested.
  • Create a mock machine and a mock circuit.
  • Call the new function a few times and check that circ->padding_apply_coin_tossed is behaving properly.

I think this can be done without mocking crypto_rand_double() but you could also mock it so that it returns predictable stuff to make it more easy.

comment:6 Changed 16 months ago by asn

Status: needs_reviewneeds_revision

comment:7 Changed 16 months ago by asn

BTW as a more general comment in this ticket, we should think a lot before we use this feature because the overhead danger is high (depending on the probability) and reaping the benefits is not always as straightforward.

For example, consider using this feature for ticket #28634 to make general circuits look more random and blend in with random-lookin HS circuits. In that case, it's true that we increase the false positive rate of identifying a single intro or rend circuit, but if you look at the whole HS circuit dance, you can see that an HS client starts using 2 circuits at the same time (intro and rend, let's ignore hsdir for now). This ticket won't make normal clients start using 2 circuits at once, so even tho a single circuit might look random if the probability triggers, the fact that it's missing the second circuit might still act as an identifier in that the session is not actually an HS dance and it's faking it.

comment:8 Changed 16 months ago by mikeperry

Parent ID: #28634

No longer needed for #28634. I started working on this in mikeperry-github/ticket30092 (same PR; WIP commit there that doesn't compile) but I'm going to switch to higher prio tickets before finishing this up.

comment:9 Changed 15 months ago by mikeperry

Keywords: 041-proposed removed
Milestone: Tor: 0.4.1.x-final

I agree with asn in comment:7. This may or may not help, and it seems like we'll need a probability_to_launch_new_circ option as well, somehow, if we do need this.

Please let me know if this seems useful for padding research.

comment:10 Changed 15 months ago by asn

Milestone: Tor: unspecified

comment:11 Changed 11 months ago by mikeperry

Keywords: circpad-researchers-maybe-want added
Note: See TracTickets for help on using tickets.