Re: [tor-bugs] #17349 [Tor]: Create an ed25519 shared randomness key for dirauths

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17349: Create an ed25519 shared randomness key for dirauths
--------------------+------------------------------------
 Reporter:  asn     |          Owner:
     Type:  defect  |         Status:  needs_review
 Priority:  High    |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor     |        Version:
 Severity:  Normal  |     Resolution:
 Keywords:          |  Actual Points:
Parent ID:  #16943  |         Points:
  Sponsor:          |
--------------------+------------------------------------

Comment (by s7r):

 Maybe this is helpful. From the little C I could make sense of, I think
 that the code in `prop250-ed25519-day2` branch currently keeps a separate
 `SharedRandomKeyLifetime`. Maybe this logic will make sense and simplify a
 little bit. Here goes:

 Everything additional should happen after `load_ed_keys()` does the
 existent checks to keep a logic.
 1. On fresh start or HUP signal, after doing all the existent checks for
 ed25519 identity keys, '''only if we are an authority''': also check if
 '''ed25519_shared_random_secret_key''' and
 '''ed25519_shared_random_cert''' files exist in $datadirectory/keys.

 2. If these files are missing (or just one of them is missing, doesn't
 matter):
 - generate a new '''ed25519_shared_random_secret_key''' and an
 '''ed25519_shared_random_cert''' chained to
 '''ed25519_signing_secret_key'''. '''When generating the
 ed25519_shared_random_cert, also check the expiration timestamp of
 ed25519_signing_cert and copy/paste it.''' Since Tor will first do the
 checks for ed25519_signing_secret_key and ed25519_signing_cert, and only
 after this, in order, the checks for ed25519_shared_random*, this step
 cannot go wrong. (this way we avoid the need for a
 `SharedRandomKeyLifetime` and we rely on the checks and thresholds
 implemented for `SigningKeyLifetime`)

 3. If '''ed25519_shared_random_secret_key''' and
 '''ed25519_shared_random_cert''' both exist in $datadirectory/keys:
 - first, '''check if expiration timestamp of ed25519_shared_random_cert ==
 expiration timestamp of ed25519_signing_cert'''. If not, it means the
 ed25519_signing_secret_key has changed, so delete
 ed25519_shared_random_secret_key and ed25519_shared_random_cert entirely
 and fail back to step 2. Only if is the same or is not the same logic
 should matter here, since we can generate a medium term signing key valid
 for 100 days and reconsider after 2 days and issue a new one valid for 60
 days, so the expiration timestamp of ed25519_signing_cert will go back
 from let's say 30.04.2016 to 20.03.2016. If ed25519_shared_random_cert is
 expired, implicitly ed25519_signing_cert is expired so Tor will either not
 start at all either generate valid medium term signing key. This makes it
 impossible to reach this step with an expired ed25519_signing_cert (it is
 checked before this step, at the checks for ed25519 identity keys).

 - second, if the expiration timestamps in both certificates match,
 '''check if ed25519_shared_random_cert is valid and properly chains
 ed25519_shared_random_secret_key to ed25519_signing_secret_key'''. If they
 somehow do not match, delete ed25519_shared_random_secret_key and
 ed25519_shared_random_cert entirely and fail back to step 2.(this way we
 rely on the already existent `need_new_signing_key` and
 `want_new_signing_key`)

 4. Proceed if all these went well as normally. Unlike
 ed25519_signing_secret_key - when the ed25519_master_id_secret_key is kept
 offline or encrypted, there is no excuse for not being able to
 automatically generate an ed25519_shared_random_secret_key and
 ed25519_shared_random_cert if we follow all the steps in the logic order,
 so the above checks should be sufficient.

 asn:
 I am sorry if I am missing something obvious, but why do the other
 authorities need to parse the shared randomness keys and not just the
 commitment or reveal values + signatures of each participant? Can't the
 other directory authorities, when receiving a vote, tell just from the
 signature included with each commit or reveal if it belongs to a key
 (shared randomness key) that at a certain timestamp (commitment or reveal
 timestamp) was valid (properly chained) to the
 ed25519_master_id_public_key (ed25519 identity) of the directory authority
 that broadcasted it? So any other authority will validate itself a
 conflict (0 trust in other players) just by checking the signatures and
 comparing the commit / reveal values. If more data is required, better
 make signatures slightly bigger and include within each signature what
 else is needed to verify each signature at any time by anyone.

 If the other authorities can verify this just from the signatures, there
 is no security benefit for parsing the ed25519 shared randomness keys,
 given there is a 100% chance that they will change during protocol run at
 some moment anyway.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17349#comment:12>
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