[tor-dev] How do Ed25519 relay IDs look like?

[Nick Mathewson]

On Sun, Oct 10, 2021 at 5:13 PM nusenu <nusenu-lists at riseup.net> wrote:
>
> > On Tue, Aug 4, 2020 at 6:41 PM nusenu <nusenu-lists at riseup.net> wrote:
> >>
> >> nusenu:
> >>> I'll wait until you (Tor developers) decided on the final naming and format
> >>
> >> Is there any interest to move this topic forward to come to some decision
> >> in the near future? (before the end of the month)
> >
> > I don't think that'd be too hard.
> >
> >> Here is a short summary of what opinions I observed for this topic (naming and format
> >> for Ed25519 identities) so far:
> >>
> >> Naming proposals for relay Ed25519 identities:
> >> ------------------------------------
> >>
> >> 'v2 fingerprints' (Damian)
> >>
> >> "ed25519 identity" or even just "identity" (nickm)
> >>
> >>
> >> Output format the Ed25519 relay IDs:
> >> ------------------------------------
> >>
> >> base64 - 43 characters long (nickm)
> >>    this is problematic due to the "/" sign (Damian)
> >> hex - 64 characters long (Damian)
> >>    "/" is problematic for DirPort urls, GETINFO commands, etc (Damian)
> >>      isn't there urlencoding for URLs? (nusenu)
> >> base64urlsafe - 43 characters long (nusenu)
> >>
> >> I hope we can agree to use the same format in all places.
> >>
> >> How does the decision process looks like in general in the Tor Project?
> >
> > I think right now Tor uses unpadded base64 in most internal formats,
> > but it doesn't actually use those in the user interface anywhere, so
> > we could just use base64urlsafe (per rfc4648 section 5) for the user
> > interface.
> >
> > I would be fine with standardizing that for our API, but I'd want to
> > write a proposal for it first.  It wouldn't have to be long.  We'd
> > want to describe other places where we currently use regular base64
> > for 256-bit keys, and say whether we should/shouldn't accept and emit
> > url-safe identifiers there instead.
> >
> > We should specify that there are no spaces, that the padding "="
> > characters are removed, and that even though the format as given can
> > handle 43*6==258 bits, the last two bits must be set to 0, since these
> > are only 256-bit identifiers.
> >
> > We should also _probably_ specify some canonical encoding for a pair of keys.
> >
>
> I've come to the conclusion that since people are used so much to the fact
> that relay ID's (RSA) never were case sensitive, ed25519 should not
> be case sensitive either.
>
> So I'd propose to use base32 without padding.
> That would make it 52 chars long.
>
> Any opinions?
>

Hm.  Every time we've displayed Ed25519 fingerprints so far, we've
used base64.  I'm not sure that changing it will actually save more
confusion than it causes.

yrs,
-- 
Nick