[tor-bugs] #17435 [Core Tor/Tor]: Patch dir-spec with the shared randomness info

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon May 9 20:52:25 UTC 2016


#17435: Patch dir-spec with the shared randomness info
------------------------------+------------------------------------
 Reporter:  asn               |          Owner:  asn
     Type:  defect            |         Status:  needs_review
 Priority:  Medium            |      Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor      |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  tor-spec, tor-hs  |  Actual Points:
Parent ID:  #16943            |         Points:  small
 Reviewer:                    |        Sponsor:  SponsorR-can
------------------------------+------------------------------------

Comment (by 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?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17435#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list