-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/06/15 17:48, Nick Mathewson wrote:
On Mon, Jun 1, 2015 at 3:27 AM, Karsten Loesing karsten@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@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.)
Great, thanks!
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).
Okay.
"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? :)
Not sure. I haven't actually added either yet; does the status quo not work?
Well, it's the same use case. People would be able to grep extra-info descriptors for a given identity string, rather than having to use a specialized tool for that. It think it would be useful to have.
(And it would allow me to ignore the identity-ed25519 crypto block entirely rather than having to parse the contained data structure and pick the bytes I want.)
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.
I'm fine with either solution. If your preference is to add another master-key-ed25519 line (and if you agree that it would make sense to have the plain-text master key in extra-info descriptors at all), sounds good to me.
Thanks!
All the best, Karsten