Opened 22 months ago

Closed 7 months ago

#17434 closed enhancement (implemented)

DocTor should understand the shared randomness protocol

Reported by: asn Owned by: atagar
Priority: Medium Milestone:
Component: Core Tor/DocTor Version:
Severity: Normal Keywords:
Cc: dgoulet Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

There are a few partioning attacks on the shared randomness protocol (#16943) that are not easy to fix. The attacks are not that dangerous and they are quite detectable. It would be nice if DocTor could catch them.

Some detection ideas can be found in this mail:

https://lists.torproject.org/pipermail/tor-dev/2015-September/009460.html

Thanks!

Child Tickets

Change History (16)

comment:1 Changed 22 months ago by atagar

Hi asn, actually this is something David and I chatted about at the dev meeting. Is shared randomness in tor and the dir-spec? Last I checked it wasn't and isn't actionable until it it.

I appreciate the link to the email but can you give me the TL;DR version? I haven't been following the discussion to know what 'Commitment Phase' is or any of the rest. All I honestly care about is the mechanics - 'take a look at field X in the vote, and if it's Y then send an alert of severity Z'.

comment:2 Changed 18 months ago by atagar

Resolution: user disappeared
Status: newclosed

Gonna resolve this since it doesn't look to be actionable right now. Feel free to reopen if you have a specific ask here.

comment:3 Changed 18 months ago by teor

See #16943, the shared randomness code hasn't been merged yet, and is still in proposal 250. (And it's not in the dir-spec yet.)

comment:4 Changed 18 months ago by atagar

Ok. Feel free to reopen then when it's merged and if there's something specific you want monitored.

comment:5 Changed 13 months ago by dgoulet

Parent ID: #16943
Resolution: user disappeared
Status: closedreopened
Type: defectenhancement

This has been merged to dir-spec.txt and moria1 has started to make commit so I'm reopening this so we can have it running _before_ dirauth start to upgrade to 029.

comment:6 Changed 13 months ago by dgoulet

Here is some information about what DocTor should look for:

https://storm.torproject.org/shared/nFWmJv7iSzzek1goqARb7IySKvkdIvKFFBYOjunDTSa

comment:7 in reply to:  6 Changed 13 months ago by asn

Replying to dgoulet:

Here is some information about what DocTor should look for:

https://storm.torproject.org/shared/nFWmJv7iSzzek1goqARb7IySKvkdIvKFFBYOjunDTSa

Took a look and I find the attack detection heuristics reasonable.

In section 3) Missing shared random value (SRV) we have:

Two lines we are looking for in the consensus:

    "shared-rand-previous-value ..."
    "shared-rand-current-value ..."

If one of those lines is not present in the consensus, warning.

I imagine that we are going to be missing an SRV for the first few months of deploying this feature simply because not enough dirauths support it. Do we actually want to warn everytime?

Maybe we should warn only after we've seen SRVs in the past? Or maybe if enough people had participated in previous rounds of the protocol? Not sure how easy these things can be done in DocTor.

comment:8 Changed 13 months ago by atagar

Left this question on irc but might as well move it here. Is there any reason not to have the authorities start participate in shared randomness now, and do the DocTor checks afterward? Seems good to have the authorities in place well before it's used by clients anyway.

The DocTor checks will be easier to write and test when shared randomness is in the live votes.

comment:9 Changed 13 months ago by atagar

Chatted from asn and we're gonna defer on this until after shared randomness is in the live consensus. Give me a nudge when it's live and I'd be happy to implement the checks.

comment:10 Changed 10 months ago by dgoulet

@atagar, I was thinking, if you want to build that module in DocTor, we can totally use the test network to run it there as it's fully using shared random there. As you wish :).

comment:11 Changed 10 months ago by atagar

Think I'll pass. There's no rush with this and I'd rather not teach DocTor to use the test network.

comment:12 Changed 8 months ago by dgoulet

Oki! Now that 029 is stable, we already have 5 dirauth speaking that protocol which means that in around 36 hours, if all goes well, we'll have a shared random value created.

Thus this DocTor check is becoming important to have.

comment:13 Changed 8 months ago by atagar

Hi David, just a quick note to say this has bubbled up to the top of my todo list (sadly in part by knocking #20969 off of it). Hopefully I'll have something here in the next few days.

comment:14 Changed 7 months ago by atagar

Status: reopenedneeds_review

Hi George, hi David. Sorry about the long delay here. Pushed checks #1-3 to my ticket1434 branch. Check #4 requires remembering values from hour to hour and DocTor is largely stateless so unless it's vital I'm passing on that one.

Mind reviewing the changes to make sure they're what you want?

https://gitweb.torproject.org/user/atagar/doctor.git/log/?h=ticket17434

comment:15 Changed 7 months ago by dgoulet

Looks good! No idea if it actually works but I'll trust you on that!

Is this detection is reasonable to do with DocTor you think? Quoting the tor-dev@ email:

It would also be useful if consensus-health fetched all the votes *seen* by an
authority, and not just the one it publishes. This way we can find attacks where
the attacker sends different votes to different honest auths. We can fetch the
alien votes seen by an authority using the URL tor/status-vote/next/<fp>.z .

comment:16 Changed 7 months ago by atagar

Resolution: implemented
Status: needs_reviewclosed

Hi David. Downloading n2 vote documents would be very expensive. If such a check is critical it could be implemented but it would be separate from the main consensus health script.

Pushing these new checks and giving 'em a whirl. Feel free to reopen if you need anything else.

Note: See TracTickets for help on using tickets.