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

[nusenu]

> 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?

kind regards,
nusenu

-- 
https://nusenu.github.io