-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Nick,
On 31/05/15 16:21, Nick Mathewson wrote:
On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing karsten@torproject.org wrote:
So, I think a "fingerprint-ed25519" line would be useful. It would make the bridge descriptor sanitizing process much easier. It would also facilitate debugging network problems, because people can just grep descriptors rather than using specialized tools that know how to decode the cert. And with microdescriptors in place it should be okay to add this line even if it's redundant information, because clients would never download it.
Hm. Okay, that sounds solid enough. I'll try to hack it in tonight or Monday, and add it to prop220.
Sounds good. Thanks!
If the server descriptor in #16227 were a bridge descriptor, I'd do the following steps for sanitizing it:
- Remove identity-ed25519 line and subsequent crypto block.
+1
Okay.
- Keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its
value. - Keep extra-info digest line, but SHA1 and SHA256 its values.
Suggestion: Don't use raw SHA256(x) but instead use SHA256("sanitize ID for bridge descriptor" | x) or SHA256("sanitize extra-info digest for bridge descriptor" | x). That way we don't need to worry about colliding with something else that decides to SHA256 these.
Hmm, actually I worry more about simplicity here than possible SHA256 collisions. This algorithm needs to be implemented in various places and sometimes even performed manually:
- `router_write_fingerprint(int hashed)` in router.c: for the log line and hashed-fingerprint file (want me to add a ticket for this, btw?), - Nyx (formerly known as arm): to display the hashed fingerprint that users can paste into Atlas/Globe, - Atlas/Globe: to make sure that only hashed fingerprints are submitted to Onionoo, - Onionoo: to make sure we also return relays that had their identity hashed by Atlas/Globe and bridges that had their identity hashed twice, - CollecTor: to sanitize bridge descriptors, - bridge operators/BridgeDB devs: to find out more details about a bridge that they only have a bridge network status or server descriptor for, - and maybe others.
How bad would it be to just SHA256 values for sanitizing bridge descriptors for the sake of simplicity?
- Remove onion-key line and subsequent crypto block. - Remove
signing-key line and subsequent crypto block. - Remove onion-key-crosscert line and subsequent crypto block. - Remove ntor-onion-key-crosscert line and subsequent crypto block. - Keep ntor-onion-key line, mostly because we didn't remove it so far; unless it should be removed? - Remove router-sig-ed25519 line. - Remove router-signature line and subsequent crypto block. - Add router-digest line with SHA1 of SHA1 of descriptor content and SHA256 of SHA256 of descriptor content; the rationale is that we don't have to write entirely new digests into the network status in order to match "r" lines with descriptors.
That all sounds fine.
Cool.
I also added the extra-info descriptor that corresponds to the server descriptor to #16227:
https://trac.torproject.org/projects/tor/ticket/16227#comment:5
I wonder, what's the best way for including the ed25519 identity in the extra-info descriptor? How about extending the first line to:
"extra-info Truie SHA1-of-RSA SHA256-of-ed25519"
Possible downsides are that this additional value might break existing code and that it might be problematic to get rid of the SHA1-of-RSA part later. But the same issues would come up with the "extra-info-digest" line in server descriptors, and maybe there are good solutions.
Otherwise, a separate "fingerprint-ed25519" line might work here, too.
Plausible.
Which one, the extended "extra-info" line or the additional "fingerprint-ed25519" line? :)
In order to sanitize such an extra-info descriptor, I'd do these steps:
- Keep extra-info line, but SHA1 (and possibly SHA256) its
value(s).
See above.
- Or, keep yet-to-be-added fingerprint-ed25519 line, but SHA256
its value.
See above.
- Remove router-sig-ed25519 line. - Remove router-signature line
and subsequent crypto block. - Add router-digest line with SHA1 of SHA1 of descriptor content and SHA256 of SHA256 of descriptor content; same rationale as above, but with the "extra-info-digest" line in server descriptors.
What do you think?
Sounds fine.
Thanks for looking!
All the best, Karsten