srv-spec.txt 28 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640
  1. Tor Shared Random Subsystem Specification
  2. This document specifies how the commit-and-reveal shared random subsystem of
  3. Tor works. This text used to be proposal 250-commit-reveal-consensus.txt.
  4. Table Of Contents:
  5. 1. Introduction
  6. 1.1. Motivation
  7. 1.2. Previous work
  8. 2. Overview
  9. 2.1. Introduction to our commit-and-reveal protocol
  10. 2.2. Ten thousand feet view of the protocol
  11. 2.3. How we use the consensus [CONS]
  12. 2.3.1. Inserting Shared Random Values in the consensus
  13. 2.4. Persistent State of the Protocol [STATE]
  14. 2.5. Protocol Illustration
  15. 3. Protocol
  16. 3.1 Commitment Phase [COMMITMENTPHASE]
  17. 3.1.1. Voting During Commitment Phase
  18. 3.1.2. Persistent State During Commitment Phase [STATECOMMIT]
  19. 3.2 Reveal Phase
  20. 3.2.1. Voting During Reveal Phase
  21. 3.2.2. Persistent State During Reveal Phase [STATEREVEAL]
  22. 3.3. Shared Random Value Calculation At 00:00UTC
  23. 3.3.1. Shared Randomness Calculation [SRCALC]
  24. 3.4. Bootstrapping Procedure
  25. 3.5. Rebooting Directory Authorities [REBOOT]
  26. 4. Specification [SPEC]
  27. 4.1. Voting
  28. 4.1.1. Computing commitments and reveals [COMMITREVEAL]
  29. 4.1.2. Validating commitments and reveals [VALIDATEVALUES]
  30. 4.1.4. Encoding commit/reveal values in votes [COMMITVOTE]
  31. 4.1.5. Shared Random Value [SRVOTE]
  32. 4.2. Encoding Shared Random Values in the consensus [SRCONSENSUS]
  33. 4.3. Persistent state format [STATEFORMAT]
  34. 5. Security Analysis
  35. 5.1. Security of commit-and-reveal and future directions
  36. 5.2. Predicting the shared random value during reveal phase
  37. 5.3. Partition attacks
  38. 5.3.1. Partition attacks during commit phase
  39. 5.3.2. Partition attacks during reveal phase
  40. 6. Discussion
  41. 6.1. Why the added complexity from proposal 225?
  42. 6.2. Why do you do a commit-and-reveal protocol in 24 rounds?
  43. 6.3. Why can't we recover if the 00:00UTC consensus fails?
  44. 7. Acknowledgements
  45. 1. Introduction
  46. 1.1. Motivation
  47. For the next generation hidden services project, we need the Tor network to
  48. produce a fresh random value every day in such a way that it cannot be
  49. predicted in advance or influenced by an attacker.
  50. Currently we need this random value to make the HSDir hash ring
  51. unpredictable (#8244), which should resolve a wide class of hidden service
  52. DoS attacks and should make it harder for people to gauge the popularity
  53. and activity of target hidden services. Furthermore this random value can
  54. be used by other systems in need of fresh global randomness like
  55. Tor-related protocols (e.g. OnioNS) or even non-Tor-related (e.g. warrant
  56. canaries).
  57. 1.2. Previous work
  58. Proposal 225 specifies a commit-and-reveal protocol that can be run as an
  59. external script and have the results be fed to the directory authorities.
  60. However, directory authority operators feel unsafe running a third-party
  61. script that opens TCP ports and accepts connections from the Internet.
  62. Hence, this proposal aims to embed the commit-and-reveal idea in the Tor
  63. voting process which should make it smoother to deploy and maintain.
  64. Another idea proposed specifically for Tor is Nick Hopper's "A threshold
  65. signature-based proposal for a shared RNG" which was never turned into an
  66. actual Tor proposal.
  67. 2. Overview
  68. This proposal alters the Tor consensus protocol such that a random number is
  69. generated every midnight by the directory authorities during the regular voting
  70. process. The distributed random generator scheme is based on the
  71. commit-and-reveal technique.
  72. The proposal also specifies how the final shared random value is embedded
  73. in consensus documents so that clients who need it can get it.
  74. 2.1. Introduction to our commit-and-reveal protocol
  75. Every day, before voting for the consensus at 00:00UTC each authority
  76. generates a new random value and keeps it for the whole day. The authority
  77. cryptographically hashes the random value and calls the output its
  78. "commitment" value. The original random value is called the "reveal" value.
  79. The idea is that given a reveal value you can cryptographically confirm that
  80. it corresponds to a given commitment value (by hashing it). However given a
  81. commitment value you should not be able to derive the underlying reveal
  82. value. The construction of these values is specified in section [COMMITREVEAL].
  83. 2.1. Ten thousand feet view of the protocol
  84. Our commit-and-reveal protocol aims to produce a fresh shared random value
  85. everyday at 00:00UTC. The final fresh random value is embedded in the
  86. consensus document at that time.
  87. Our protocol has two phases and uses the hourly voting procedure of Tor.
  88. Each phase lasts 12 hours, which means that 12 voting rounds happen in
  89. between. In short, the protocol works as follows:
  90. Commit phase:
  91. Starting at 00:00UTC and for a period of 12 hours, authorities every
  92. hour include their commitment in their votes. They also include any
  93. received commitments from other authorities, if available.
  94. Reveal phase:
  95. At 12:00UTC, the reveal phase starts and lasts till the end of the
  96. protocol at 00:00UTC. In this stage, authorities must reveal the value
  97. they committed to in the previous phase. The commitment and revealed
  98. values from other authorities, when available, are also added to the
  99. vote.
  100. Shared Randomness Calculation:
  101. At 00:00UTC, the shared random value is computed from the agreed
  102. revealed values and added to the consensus.
  103. This concludes the commit-and-reveal protocol at 00:00UTC everyday.
  104. 2.3. How we use the consensus [CONS]
  105. The produced shared random values needs to be readily available to
  106. clients. For this reason we include them in the consensus documents.
  107. Every hour the consensus documents need to include the shared random value
  108. of the day, as well as the shared random value of the previous day. That's
  109. because either of these values might be needed at a given time for a Tor
  110. client to access a hidden service according to section [TIME-OVERLAP] of
  111. proposal 224. This means that both of these two values need to be included
  112. in votes as well.
  113. Hence, consensuses need to include:
  114. (a) The shared random value of the current time period.
  115. (b) The shared random value of the previous time period.
  116. For this, a new SR consensus method will be needed to indicate which
  117. authorities support this new protocol.
  118. 2.3.1. Inserting Shared Random Values in the consensus
  119. After voting happens, we need to be careful on how we pick which shared
  120. random values (SRV) to put in the consensus, to avoid breaking the consensus
  121. because of authorities having different views of the commit-and-reveal
  122. protocol (because maybe they missed some rounds of the protocol).
  123. For this reason, authorities look at the received votes before creating a
  124. consensus and employ the following logic:
  125. - First of all, they make sure that the agreed upon consensus method is
  126. above the SR consensus method.
  127. - Authorities include an SRV in the consensus if and only if the SRV has
  128. been voted by at least the majority of authorities.
  129. - For the consensus at 00:00UTC, authorities include an SRV in the consensus
  130. if and only if the SRV has been voted by at least AuthDirNumAgreements
  131. authorities (where AuthDirNumAgreements is a newly introduced consensus
  132. parameter).
  133. Authorities include in the consensus the most popular SRV that also
  134. satisfies the above constraints. Otherwise, no SRV should be included.
  135. The above logic is used to make it harder to break the consensus by natural
  136. partioning causes.
  137. We use the AuthDirNumAgreements consensus parameter to enforce that a
  138. _supermajority_ of dirauths supports the SR protocol during SRV creation, so
  139. that even if a few of those dirauths drop offline in the middle of the run
  140. the SR protocol does not get disturbed. We go to extra lengths to ensure
  141. this because changing SRVs in the middle of the day has terrible
  142. reachability consequences for hidden service clients.
  143. 2.4. Persistent State of the Protocol [STATE]
  144. A directory authority needs to keep a persistent state on disk of the on
  145. going protocol run. This allows an authority to join the protocol seamlessly
  146. in the case of a reboot.
  147. During the commitment phase, it is populated with the commitments of all
  148. authorities. Then during the reveal phase, the reveal values are also
  149. stored in the state.
  150. As discussed previously, the shared random values from the current and
  151. previous time period must also be present in the state at all times if they
  152. are available.
  153. 2.5. Protocol Illustration
  154. An illustration for better understanding the protocol can be found here:
  155. https://people.torproject.org/~asn/hs_notes/shared_rand.jpg
  156. It reads left-to-right.
  157. The illustration displays what the authorities (A_1, A_2, A_3) put in their
  158. votes. A chain 'A_1 -> c_1 -> r_1' denotes that authority A_1 committed to
  159. the value c_1 which corresponds to the reveal value r_1.
  160. The illustration depicts only a few rounds of the whole protocol. It starts
  161. with the first three rounds of the commit phase, then it jumps to the last
  162. round of the commit phase. It continues with the first two rounds of the
  163. reveal phase and then it jumps to the final round of the protocol run. It
  164. finally shows the first round of the commit phase of the next protocol run
  165. (00:00UTC) where the final Shared Random Value is computed. In our fictional
  166. example, the SRV was computed with 3 authority contributions and its value
  167. is "a56fg39h".
  168. We advice you to revisit this after you have read the whole document.
  169. 3. Protocol
  170. In this section we give a detailed specification of the protocol. We
  171. describe the protocol participants' logic and the messages they send. The
  172. encoding of the messages is specified in the next section ([SPEC]).
  173. Now we go through the phases of the protocol:
  174. 3.1 Commitment Phase [COMMITMENTPHASE]
  175. The commit phase lasts from 00:00UTC to 12:00UTC.
  176. During this phase, an authority commits a value in its vote and
  177. saves it to the permanent state as well.
  178. Authorities also save any received authoritative commits by other authorities
  179. in their permanent state. We call a commit by Alice "authoritative" if it was
  180. included in Alice's vote.
  181. 3.1.1. Voting During Commitment Phase
  182. During the commit phase, each authority includes in its votes:
  183. - The commitment value for this protocol run.
  184. - Any authoritative commitments received from other authorities.
  185. - The two previous shared random values produced by the protocol (if any).
  186. The commit phase lasts for 12 hours, so authorities have multiple chances to
  187. commit their values. An authority MUST NOT commit a second value during a
  188. subsequent round of the commit phase.
  189. If an authority publishes a second commitment value in the same commit
  190. phase, only the first commitment should be taken in account by other
  191. authorities. Any subsequent commitments MUST be ignored.
  192. 3.1.2. Persistent State During Commitment Phase [STATECOMMIT]
  193. During the commitment phase, authorities save in their persistent state the
  194. authoritative commits they have received from each authority. Only one commit
  195. per authority must be considered trusted and active at a given time.
  196. 3.2 Reveal Phase
  197. The reveal phase lasts from 12:00UTC to 00:00UTC.
  198. Now that the commitments have been agreed on, it's time for authorities to
  199. reveal their random values.
  200. 3.2.1. Voting During Reveal Phase
  201. During the reveal phase, each authority includes in its votes:
  202. - Its reveal value that was previously committed in the commit phase.
  203. - All the commitments and reveals received from other authorities.
  204. - The two previous shared random values produced by the protocol (if any).
  205. The set of commitments have been decided during the commitment
  206. phase and must remain the same. If an authority tries to change its
  207. commitment during the reveal phase or introduce a new commitment,
  208. the new commitment MUST be ignored.
  209. 3.2.2. Persistent State During Reveal Phase [STATEREVEAL]
  210. During the reveal phase, authorities keep the authoritative commits from the
  211. commit phase in their persistent state. They also save any received reveals
  212. that correspond to authoritative commits and are valid (as specified in
  213. [VALIDATEVALUES]).
  214. An authority that just received a reveal value from another authority's vote,
  215. MUST wait till the next voting round before including that reveal value in
  216. its votes.
  217. 3.3. Shared Random Value Calculation At 00:00UTC
  218. Finally, at 00:00UTC every day, authorities compute a fresh shared random
  219. value and this value must be added to the consensus so clients can use it.
  220. Authorities calculate the shared random value using the reveal values in
  221. their state as specified in subsection [SRCALC].
  222. Authorities at 00:00UTC start including this new shared random value in
  223. their votes, replacing the one from two protocol runs ago. Authorities also
  224. start including this new shared random value in the consensus as well.
  225. Apart from that, authorities at 00:00UTC proceed voting normally as they
  226. would in the first round of the commitment phase (section [COMMITMENTPHASE]).
  227. 3.3.1. Shared Randomness Calculation [SRCALC]
  228. An authority that wants to derive the shared random value SRV, should use
  229. the appropriate reveal values for that time period and calculate SRV as
  230. follows.
  231. HASHED_REVEALS = H(ID_a | R_a | ID_b | R_b | ..)
  232. SRV = SHA3-256("shared-random" | INT_8(REVEAL_NUM) | INT_4(VERSION) |
  233. HASHED_REVEALS | PREVIOUS_SRV)
  234. where the ID_a value is the identity key fingerprint of authority 'a' and R_a
  235. is the corresponding reveal value of that authority for the current period.
  236. Also, REVEAL_NUM is the number of revealed values in this construction,
  237. VERSION is the protocol version number and PREVIOUS_SRV is the previous
  238. shared random value. If no previous shared random value is known, then
  239. PREVIOUS_SRV is set to 32 NUL (\x00) bytes.
  240. To maintain consistent ordering in HASHED_REVEALS, all the ID_a | R_a pairs
  241. are ordered based on the R_a value in ascending order.
  242. 3.4. Bootstrapping Procedure
  243. As described in [CONS], two shared random values are required for the HSDir
  244. overlay periods to work properly as specified in proposal 224. Hence
  245. clients MUST NOT use the randomness of this system till it has bootstrapped
  246. completely; that is, until two shared random values are included in a
  247. consensus. This should happen after three 00:00UTC consensuses have been
  248. produced, which takes 48 hours.
  249. 3.5. Rebooting Directory Authorities [REBOOT]
  250. The shared randomness protocol must be able to support directory
  251. authorities who leave or join in the middle of the protocol execution.
  252. An authority that commits in the Commitment Phase and then leaves MUST have
  253. stored its reveal value on disk so that it continues participating in the
  254. protocol if it returns before or during the Reveal Phase. The reveal value
  255. MUST be stored timestamped to avoid sending it on wrong protocol runs.
  256. An authority that misses the Commitment Phase cannot commit anymore, so it's
  257. unable to participate in the protocol for that run. Same goes for an
  258. authority that misses the Reveal phase. Authorities who do not participate in
  259. the protocol SHOULD still carry commits and reveals of others in their vote.
  260. Finally, authorities MUST implement their persistent state in such a way that they
  261. will never commit two different values in the same protocol run, even if they
  262. have to reboot in the middle (assuming that their persistent state file is
  263. kept). A suggested way to structure the persistent state is found at [STATEFORMAT].
  264. 4. Specification [SPEC]
  265. 4.1. Voting
  266. This section describes how commitments, reveals and SR values are encoded in
  267. votes. We describe how to encode both the authority's own
  268. commitments/reveals and also the commitments/reveals received from the other
  269. authorities. Commitments and reveals share the same line, but reveals are
  270. optional.
  271. Participating authorities need to include the line:
  272. "shared-rand-participate"
  273. in their votes to announce that they take part in the protocol.
  274. 4.1.1. Computing commitments and reveals [COMMITREVEAL]
  275. A directory authority that wants to participate in this protocol needs to
  276. create a new pair of commitment/reveal values for every protocol
  277. run. Authorities SHOULD generate a fresh pair of such values right before the
  278. first commitment phase of the day (at 00:00UTC).
  279. The value REVEAL is computed as follows:
  280. REVEAL = base64-encode( TIMESTAMP || H(RN) )
  281. where RN is the SHA3 hashed value of a 256-bit random value. We hash the
  282. random value to avoid exposing raw bytes from our PRNG to the network (see
  283. [RANDOM-REFS]).
  284. TIMESTAMP is an 8-bytes network-endian time_t value. Authorities SHOULD
  285. set TIMESTAMP to the valid-after time of the vote document they first plan
  286. to publish their commit into (so usually at 00:00UTC, except if they start
  287. up in a later commit round).
  288. The value COMMIT is computed as follows:
  289. COMMIT = base64-encode( TIMESTAMP || H(REVEAL) )
  290. 4.1.2. Validating commitments and reveals [VALIDATEVALUES]
  291. Given a COMMIT message and a REVEAL message it should be possible to verify
  292. that they indeed correspond. To do so, the client extracts the random value
  293. H(RN) from the REVEAL message, hashes it, and compares it with the H(H(RN))
  294. from the COMMIT message. We say that the COMMIT and REVEAL messages
  295. correspond, if the comparison was successful.
  296. Pariticipants MUST also check that corresponding COMMIT and REVEAL values
  297. have the same timestamp value.
  298. Authorities should ignore reveal values during the Reveal Phase that don't
  299. correspond to commit values published during the Commitment Phase.
  300. 4.1.4. Encoding commit/reveal values in votes [COMMITVOTE]
  301. An authority puts in its vote the commitments and reveals it has produced and
  302. seen from the other authorities. To do so, it includes the following in its
  303. votes:
  304. "shared-rand-commit" SP VERSION SP ALGNAME SP IDENTITY SP COMMIT [SP REVEAL] NL
  305. where VERSION is the version of the protocol the commit was created with.
  306. IDENTITY is the authority's SHA1 identity fingerprint and COMMIT is the
  307. encoded commit [COMMITREVEAL]. Authorities during the reveal phase can
  308. also optionally include an encoded reveal value REVEAL. There MUST be only
  309. one line per authority else the vote is considered invalid. Finally, the
  310. ALGNAME is the hash algorithm that should be used to compute COMMIT and
  311. REVEAL which is "sha3-256" for version 1.
  312. 4.1.5. Shared Random Value [SRVOTE]
  313. Authorities include a shared random value (SRV) in their votes using the
  314. following encoding for the previous and current value respectively:
  315. "shared-rand-previous-value" SP NUM_REVEALS SP VALUE NL
  316. "shared-rand-current-value" SP NUM_REVEALS SP VALUE NL
  317. where VALUE is the actual shared random value encoded in hex (computed as
  318. specified in section [SRCALC]. NUM_REVEALS is the number of reveal values
  319. used to generate this SRV.
  320. To maintain consistent ordering, the shared random values of the previous
  321. period should be listed before the values of the current period.
  322. 4.2. Encoding Shared Random Values in the consensus [SRCONSENSUS]
  323. Authorities insert the two active shared random values in the consensus
  324. following the same encoding format as in [SRVOTE].
  325. 4.3. Persistent state format [STATEFORMAT]
  326. As a way to keep ground truth state in this protocol, an authority MUST
  327. keep a persistent state of the protocol. The next sub-section suggest a
  328. format for this state which is the same as the current state file format.
  329. It contains a preamble, a commitment and reveal section and a list of
  330. shared random values.
  331. The preamble (or header) contains the following items. They MUST occur in
  332. the order given here:
  333. "Version" SP version NL
  334. [At start, exactly once.]
  335. A document format version. For this specification, version is "1".
  336. "ValidUntil" SP YYYY-MM-DD SP HH:MM:SS NL
  337. [Exactly once]
  338. After this time, this state is expired and shouldn't be used nor
  339. trusted. The validity time period is till the end of the current
  340. protocol run (the upcoming noon).
  341. The following details the commitment and reveal section. They are encoded
  342. the same as in the vote. This makes it easier for implementation purposes.
  343. "Commit" SP version SP algname SP identity SP commit [SP reveal] NL
  344. [Exactly once per authority]
  345. The values are the same as detailed in section [COMMITVOTE].
  346. This line is also used by an authority to store its own value.
  347. Finally is the shared random value section.
  348. "SharedRandPreviousValue" SP num_reveals SP value NL
  349. [At most once]
  350. This is the previous shared random value agreed on at the previous
  351. period. The fields are the same as in section [SRVOTE].
  352. "SharedRandCurrentValue" SP num_reveals SP value NL
  353. [At most once]
  354. This is the latest shared random value. The fields are the same as in
  355. section [SRVOTE].
  356. 5. Security Analysis
  357. 5.1. Security of commit-and-reveal and future directions
  358. The security of commit-and-reveal protocols is well understood, and has
  359. certain flaws. Basically, the protocol is insecure to the extent that an
  360. adversary who controls b of the authorities gets to choose among 2^b
  361. outcomes for the result of the protocol. However, an attacker who is not a
  362. dirauth should not be able to influence the outcome at all.
  363. We believe that this system offers sufficient security especially compared
  364. to the current situation. More secure solutions require much more advanced
  365. crypto and more complex protocols so this seems like an acceptable solution
  366. for now.
  367. For alternative approaches on collaborative random number generation also
  368. see the discussion at [RNGMESSAGING].
  369. 5.2. Predicting the shared random value during reveal phase
  370. The reveal phase lasts 12 hours, and most authorities will send their
  371. reveal value on the first round of the reveal phase. This means that an
  372. attacker can predict the final shared random value about 12 hours before
  373. it's generated.
  374. This does not pose a problem for the HSDir hash ring, since we impose an
  375. higher uptime restriction on HSDir nodes, so 12 hours predictability is not
  376. an issue.
  377. Any other protocols using the shared random value from this system should
  378. be aware of this property.
  379. 5.3. Partition attacks
  380. This design is not immune to certain partition attacks. We believe they
  381. don't offer much gain to an attacker as they are very easy to detect and
  382. difficult to pull off since an attacker would need to compromise a directory
  383. authority at the very least. Also, because of the byzantine general problem,
  384. it's very hard (even impossible in some cases) to protect against all such
  385. attacks. Nevertheless, this section describes all possible partition attack
  386. and how to detect them.
  387. 5.3.1. Partition attacks during commit phase
  388. A malicious directory authority could send only its commit to one single
  389. authority which results in that authority having an extra commit value for
  390. the shared random calculation that the others don't have. Since the
  391. consensus needs majority, this won't affect the final SRV value. However,
  392. the attacker, using this attack, could remove a single directory authority
  393. from the consensus decision at 24:00 when the SRV is computed.
  394. An attacker could also partition the authorities by sending two different
  395. commitment values to different authorities during the commit phase.
  396. All of the above is fairly easy to detect. Commitment values in the vote
  397. coming from an authority should NEVER be different between authorities. If
  398. so, this means an attack is ongoing or very bad bug (highly unlikely).
  399. 5.3.2. Partition attacks during reveal phase
  400. Let's consider Alice, a malicious directory authority. Alice could wait
  401. until the last reveal round, and reveal its value to half of the
  402. authorities. That would partition the authorities into two sets: the ones
  403. who think that the shared random value should contain this new reveal, and
  404. the rest who don't know about it. This would result in a tie and two
  405. different shared random value.
  406. A similar attack is possible. For example, two rounds before the end of the
  407. reveal phase, Alice could advertise her reveal value to only half of the
  408. dirauths. This way, in the last reveal phase round, half of the dirauths
  409. will include that reveal value in their votes and the others will not. In
  410. the end of the reveal phase, half of the dirauths will calculate a
  411. different shared randomness value than the others.
  412. We claim that this attack is not particularly fruitful: Alice ends up
  413. having two shared random values to chose from which is a fundamental
  414. problem of commit-and-reveal protocols as well (since the last person can
  415. always abort or reveal). The attacker can also sabotage the consensus, but
  416. there are other ways this can be done with the current voting system.
  417. Furthermore, we claim that such an attack is very noisy and detectable.
  418. First of all, it requires the authority to sabotage two consensuses which
  419. will cause quite some noise. Furthermore, the authority needs to send
  420. different votes to different auths which is detectable. Like the commit
  421. phase attack, the detection here is to make sure that the commiment values
  422. in a vote coming from an authority are always the same for each authority.
  423. 6. Discussion
  424. 6.1. Why the added complexity from proposal 225?
  425. The complexity difference between this proposal and prop225 is in part
  426. because prop225 doesn't specify how the shared random value gets to the
  427. clients. This proposal spends lots of effort specifying how the two shared
  428. random values can always be readily accessible to clients.
  429. 6.2. Why do you do a commit-and-reveal protocol in 24 rounds?
  430. The reader might be wondering why we span the protocol over the course of a
  431. whole day (24 hours), when only 3 rounds would be sufficient to generate a
  432. shared random value.
  433. We decided to do it this way, because we piggyback on the Tor voting
  434. protocol which also happens every hour.
  435. We could instead only do the shared randomness protocol from 21:00 to 00:00
  436. every day. Or to do it multiple times a day.
  437. However, we decided that since the shared random value needs to be in every
  438. consensus anyway, carrying the commitments/reveals as well will not be a
  439. big problem. Also, this way we give more chances for a failing dirauth to
  440. recover and rejoin the protocol.
  441. 6.3. Why can't we recover if the 00:00UTC consensus fails?
  442. If the 00:00UTC consensus fails, there will be no shared random value for
  443. the whole day. In theory, we could recover by calculating the shared
  444. randomness of the day at 01:00UTC instead. However, the engineering issues
  445. with adding such recovery logic are too great. For example, it's not easy
  446. for an authority who just booted to learn whether a specific consensus
  447. failed to be created.
  448. 7. Acknowledgements
  449. Thanks to everyone who has contributed to this design with feedback and
  450. discussion.
  451. Thanks go to arma, ioerror, kernelcorn, nickm, s7r, Sebastian, teor, weasel
  452. and everyone else!
  453. References:
  454. [RANDOM-REFS]:
  455. http://projectbullrun.org/dual-ec/ext-rand.html
  456. https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html
  457. [RNGMESSAGING]:
  458. https://moderncrypto.org/mail-archive/messaging/2015/002032.html