Opened 3 months ago

Last modified 4 weeks ago

#28634 new defect

Design a useful padding machine that we can enable

Reported by: asn Owned by:
Priority: Very High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: wtf-pad, tor-relay, tor-cell, padding, 041-proposed
Cc: nickm Actual Points:
Parent ID: #28632 Points: 4
Reviewer: mikeperry Sponsor: Sponsor2

Description

#28142 will get merged with no active padding machine. This ticket is about designing a useful padding machine that can act as a decent testbed for the WTF-PAD project.

Child Tickets

TicketStatusOwnerSummaryComponent
#29085newWTF-PAD: Reduce monotime usage because of performance issuesCore Tor/Tor
#29204needs_revisionInspect circuit queue during padidng decisionsCore Tor/Tor

Change History (10)

comment:1 Changed 3 months ago by nickm

IMO it doesn't need to be a useful padding machine if we can't get a useful one done in time. If the best we can do is "cheap and harmless" instead of "useful", that would still give us a testbed.

comment:2 Changed 3 months ago by asn

Reviewer: mikeperry

Here are some thoughts https://github.com/torproject/tor/pull/461#discussion_r239838732

The above plan depends on getting #28780 and #28633 done in time.

comment:3 Changed 3 months ago by mikeperry

#28633 is done, I believe. #28780 could technically be called nice-to-have gravy. The machines won't be effective against any real adversary without it since lifetimes give away too much info, but we could at least test the machines.

The harmless piece is the tricky bit, though. The Padding TODO file has items for sending an ordered preference list of machine choices in the negotiation, and a way to stop re-trying negotiation if it keeps failing. One (or both) of these must be done to meet the harmless property. I *think* that having an ordered preference will be sufficient for safety, if we specify a "null" machine that is the last preference/fallback in case of error, and if you negotiate a "null" machine, you don't try to negotiate anything more on that circuit.

So if we really want something that can work in 0.4.0, we definitely need to implement this preference ordering idea with explicit "null" fallback. And then we can try to get #28780 done after that.

comment:4 Changed 7 weeks ago by asn

OK I have some WIP here: https://github.com/torproject/tor/pull/635 based on the #28780 branch.

tl;dr I made a machine that obfuscates client-side IP circuits. I did some initial testing on chutney and it seems to work okay-ish. Needs more work and feedback.

Last edited 7 weeks ago by asn (previous) (diff)

comment:5 Changed 7 weeks ago by mikeperry

Re "XXX This is not good enough since this randomization is global...This should be randomized for each circuit" in +setup_machine_states_for_hiding_ip_circuits().. This is what the circpad_state_t.length_dist is for -- it allows you to specify a probability distribution that governs how many cells the state should last for (and length_includes_nonpadding specifies if that should count nonpadding cells too).

comment:6 Changed 6 weeks ago by asn

Milestone: Tor: 0.4.0.x-finalTor: unspecified

comment:7 Changed 6 weeks ago by nickm

Keywords: 041-proposed added

comment:8 Changed 6 weeks ago by mikeperry

Points: 4

comment:9 Changed 6 weeks ago by mikeperry

Priority: MediumVery High

comment:10 Changed 4 weeks ago by nickm

Sponsor: Sponsor2
Note: See TracTickets for help on using tickets.