[tor-dev] Sanitizing bridge descriptors containing ed25519 fields
nickm at torproject.org
Mon Jun 1 15:48:25 UTC 2015
On Mon, Jun 1, 2015 at 3:27 AM, Karsten Loesing <karsten at torproject.org> wrote:
> -----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 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!
Added to code; documenting now. It's called "master-key-ed25519".
(No point in using a fingerprint, since the public key itself is only
32 bytes long.)
> How bad would it be to just SHA256 values for sanitizing bridge
> descriptors for the sake of simplicity?
Probably not too bad; but use a differentiated hash wherever possible
(like, for new stuff).
>>> "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? :)
Not sure. I haven't actually added either yet; does the status quo not work?
I think the master-key-ed25519 line is the likeliest way; I don't know
if adding an extra arg to the first line is clever.
More information about the tor-dev