[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Sanitizing bridge descriptors containing ed25519 fields
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 30/05/15 16:44, Nick Mathewson wrote:
> On Fri, May 29, 2015 at 4:23 PM, Karsten Loesing
> <karsten@xxxxxxxxxxxxxx> wrote:
>>> router euler [scrubbed] 8000 0 0 identity-ed25519 -----BEGIN
>>> ED25519 CERT----- [scrubbed] -----END ED25519 CERT-----
>>
>> Base64-decode that block, throw it into SHA256(), base64-encode
>> the result, format as block. But wouldn't the result be much
>> shorter? There's no new "fingerprint" equivalent, like
>> "fingerprint-ed25519", is there?
>
> Oh dear. That blob is a certificate, not a key. It changes over
> time, because the key that it certifies varies over time.
>
> The format is documented in section 2.1 of proposal 220; the
> actual identity key is in an extension labeled with type 04 (see
> section 2.2.1).
>
> Maybe we should add a fingerprint-ed25519 line? It would be
> redundant, but maybe valuable. What do you think?
I took a quick look at proposal 220, but not to the point that makes
me entirely certain about this ed25519 stuff. If anything below
remains unclear, that might be because I'm not clear about it myself.
Please question everything I'm saying, even more than usual.
Let's also include Damian on this thread. He usually has good ideas
about descriptors, and he knows about sanitizing bridge descriptors.
And let's add Isis who is working a lot with bridge descriptors, too.
(There may be more people we should ask, but hey, it's tor-dev@.)
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.
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 values.
- 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.
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.
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).
- Or, keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its
value.
- 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?
All the best,
Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJVaiibAAoJEJD5dJfVqbCreJ4H/0+5n3jTG/HrQ+kPH5BKcp4h
zPVQAvecuZuBTp0temY6WbjLTQZvP2FatdSE6eCwTlS6UJXwuhhrFzB+2WFE5etI
kVmvcpUi3DMCVpTYJQ1EEgPkF6OmnHFTt7juJ7fpAPlkJNptmH7Z532yIulFECj+
6XZJquawhshJagUkDnqtuFwqg2qSBgWwaAq6Z1J1rTTeLqx3xy0Rkv3J5KDc7D5F
e/pNbhDy5C6FZFIXeEa93qCCVifvPJyix+5MH9xOEBxoHYmC2gTWWP42hhereobn
UMO//kpjD3q5zSa1G4hvEJgL0gk+Ytp11px6+PGbvAopJVBMWQuioHYaDbrr2DA=
=l2SJ
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev