-----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
> <kars...@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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJVbAl7AAoJEJD5dJfVqbCrwTEIAMnXjFxwcHQUfcqozO/15gta
W7J5XNTfBFnXYy5a8ZFWRMf80+Mt+qwb9wJG2Nvjot9enBRS1Bn2TFchcKFUgEeS
U/epBGdWYgq1Uq7At7suX9AOt2SYYBKnQk3dfkvs3EJHVTWz+3s02Mh9Fz/FZl47
QcDXZkR7DYv1pu6XfVpidm4S390z5J+IuWzZGFfwTe2AElGBUQUxxLrQGPnLVCX/
Ue6WXtwgr8GvFgoXZ1ZAz43r2/P5IxCnuSsmFpKTJynvwkosK9TG/5fj/wmxxaiK
C1De+Dqfsrkket+wJQm5FUpx6wowIp5rIwkDqAgZYzwTNwViE3Ijg1nW0RtRTbg=
=ABhA
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
