[tor-dev] Sanitizing bridge descriptors containing ed25519 fields
karsten at torproject.org
Mon Jun 1 07:27:55 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 31/05/15 16:21, Nick Mathewson wrote:
> On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing
> <karsten at 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.
>> - Keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its
>> value. - Keep extra-info digest line, but SHA1 and SHA256 its
> 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
- 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.
>> I also added the extra-info descriptor that corresponds to the
>> server descriptor to #16227:
>> I wonder, what's the best way for including the ed25519 identity
>> in the extra-info descriptor? How about extending the first line
>> "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,
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
>> - Keep extra-info line, but SHA1 (and possibly SHA256) its
> 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,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
More information about the tor-dev