Add a probability-to-apply field for circuitpadidng machines
In legacy/trac#28634 (moved), 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.
Activity
changed milestone to %Tor: unspecified in legacy/trac
added actualpoints::0.5 in Legacy / Trac circpad-researchers-maybe-want in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac padding in Legacy / Trac points::2 in Legacy / Trac priority::medium in Legacy / Trac reviewer::asn in Legacy / Trac severity::normal in Legacy / Trac sponsor::2-can in Legacy / Trac status::needs-revision in Legacy / Trac tor-cell in Legacy / Trac tor-relay in Legacy / Trac type::enhancement in Legacy / Trac wtf-pad in Legacy / Trac labels
https://github.com/torproject/tor/pull/916
This was easy, but I'm not sure how best to test it. Open to suggestions if we feel it is necessary to test.
Trac:
Status: new to needs_review
Actualpoints: N/A to 0.5-
Trac:
Parent: N/A to legacy/trac#28634 (moved) 
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_tossedis 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.- Put the body of
-
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 legacy/trac#28634 (moved) 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
probabilitytriggers, 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. -
No longer needed for legacy/trac#28634 (moved). 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.
Trac:
Parent: legacy/trac#28634 (moved) to N/A -
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.
Trac:
Keywords: 041-proposed deleted, N/A added
Milestone: Tor: 0.4.1.x-final to N/A mentioned in issue legacy/trac#30172 (moved)
moved from legacy/trac#30092 (moved)
added Feature label and removed 1 deleted label
added Padding Padding Research Relay + 1 deleted label and removed 1 deleted label
added Project Ideas label
