[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17435 [Core Tor/Tor]: Patch dir-spec with the shared randomness info
#17435: Patch dir-spec with the shared randomness info
-------------------------------------------------+-------------------------
Reporter: asn | Owner: asn
Type: defect | Status:
Priority: Medium | needs_review
Component: Core Tor/Tor | Milestone: Tor:
Severity: Normal | 0.2.9.x-final
Keywords: TorCoreTeam201606, tor-spec, tor- | Version:
hs, review-group-2, | Resolution:
Parent ID: #16943 | Actual Points:
Reviewer: | Points: 1
| Sponsor:
| SponsorR-can
-------------------------------------------------+-------------------------
Changes (by asn):
* status: needs_revision => needs_review
Comment:
Replying to [comment:12 arma]:
> {{{AlgName is the hash algorithm that is used}}}
>
> What are some expected values of AlgName here? For example, what is the
default value that the new code is going to use? Usually we'll want to
specify at least one value that must be supported.
>
> {{{Identity is the authority's SHA1 identity fingerprint}}}
>
> I bet you mean the authority's SHA1 v3 identity fingerprint? If I wanted
to be really confused I might think you meant the authority's SHA1 relay
identity fingerprint.
>
> {{{"shared-rand-commit"}}}
>
> You say "any number" for votes. Are there constraints on what is allowed
to show up in a set of these lines in a given vote? For example, I would
expect that maybe there must not be more than one shared-rand-commit line
with the same identity fingerprint in a single vote?
>
> {{{Commit is the encoded commitment value in base64}}}
>
> Are there commitment values that are unacceptable? What's the format of
it?
>
> And here's where it gets exciting: what is the process of how
authorities should take in these shared-rand-commit lines, and then
compute the shared-rand-current-value line for their consensus? This needs
to be specified, or somebody trying to build a directory authority from
this spec won't be able to do it.
>
> Similarly, how do authorities generate the {{{"shared-rand-previous-
value"}}} values? I guess they're taken out of some previous consensuses
or other past state? What should a dir auth do to generate a shared-rand-
previous-value that will conform to spec and be what clients expect?
>
> {{{Min: 1. Max: <Total number of dirauths>. Default: <Total number of
dirauths>.}}}
>
> What does "max" mean in dir-spec? I worry that it means that a value
higher than max means that the consensus or vote is not conforming to the
spec, i.e. that it's an invalid consensus or vote. And if different people
have different views on how many dirauths there are, I could totally
imagine somebody being surprised by a high number here. Maybe we just want
Max as INT32_MAX?
OK I worked on the comments above, and pushed the changes in my
`prop250_dirspec` branch.
FWIW, I ended up '''not''' explaining the whole logic behind the
computation of `shared-rand-current-value` as was requested. Instead I
just linked to the right sections of proposal 250. This makes `dir-
spec.txt` less self-contained which is bad, however explaining all that
logic would basically mean copying prop250 in dir-spec.txt, and I didn't
know how to do this without messing up dir-spec even more. e.g. just
pasting the SRV computation formula would not be very useful without
specifying which commits are considered active and how commits are
validated. Let me know if you think there is a better middle ground here.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17435#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs