Tim Wilson-Brown - teor transcribed 3.7K bytes:
On 7 May 2016, at 05:17, isis isis@torproject.org wrote:
...
Let `ID` be a router's identity key taken from the router microdescriptor. In the case for relays possessing Ed25519 identity keys (c.f. Tor proposal #220), this is a 32-byte string representing the public Ed25519 identity key. For backwards and forwards compatibility with routers which do not possess Ed25519 identity keys, this is a 32-byte string created via the output of H(ID).
I don't understand why we do this backwards and forwards compatibility for ID, when the proposal only works for relays with an ed25519 key in their descriptor.
Relays have a Curve25519 "ntor-onion-key" in their microdescriptors, is that what you meant?
By "router's identity key from the microdescriptor", I was referring to either the RSA-1024 identity key which is in the "id rsa1024" lines, [0] or (whenever prop#220 features are fully available) the "id ed25519" lines (see prop#220 §3.2). [1] I was mostly concerned about the backwards-/forwards- compatibility because otherwise there would be an annoying length difference that would make things messy.
round() is underspecified here: does 0.5 round to 0 or 1? Or is it not possible to get answers that are exactly halfway between two integers?
Yes, that is under-specified. Peter fixed it in this commit. [2]
[0]: https://collector.torproject.org/recent/relay-descriptors/microdescs/micro/2... [1]: https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt... [2]: https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=draft/newhope&...