On Sat, Aug 1, 2020 at 6:10 AM nusenu nusenu-lists@riseup.net wrote:

nusenu:

...

...

The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)?

I assume the correct proposal for the Ed25519 keys is this: https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt

I'm wondering what kind of format is used for a relay's Ed25519 ID in tor?

The spec says base64:

...

When an ed25519 signature is present, there MAY be a "master-key-ed25519" element containing the base64 encoded ed25519 master key as a single argument. If it is present, it MUST match the identity key in the certificate.

examples: grep master-key-ed 2020-07-28-19-05-00-server-descriptors |head -2

master-key-ed25519 clT/2GWmTY/qU5TBGaudAIjOUUxUdKhMY/Q5riK6G2E master-key-ed25519 qDI9PbwtiKzpR9phLnWI99uimdwNW8+l9c7hDoWV9dQ

Is this the canonical format you use when referring to a relay's Ed25519 identity?

I looked at what stem does in this area [1]. It uses the more accurate name "ed25519_master_key" instead of Ed25519 ID and contains the above mentioned base64 encoded Ed25519 public master key so I assume this is the canonical format since I didn't see any other representation.

I'd like to use "ed25519 identity" or even just "identity" here going forward. While it might make sense to use other names when describing it in relation to other keys, when talking about the relay, it is an identity key.

The base64-encoded form is the best one we have; whenever we output a key, we use that format.

...

What command does a relay operator need to run to find out his relay's Ed25519 ID on the command line?

base64 encoding (parts of) the ed25519_master_id_public_key file, provides the same output as in master-key-ed25519 descriptor lines but I didn't find a spec for that key file to confirm the try and error approach or a tor command to simply output the ed25519_master_key public key in base64 format.

I'd like to add such a command, as well as support for using ed25519 keys in more places in the UI and the control API. I'm not going to have time for a while, though, but if anybody would be interested in hacking this together, I can point to some of the places in the code you'd need to change.

best wishes,

I was wondering why the base64 string is 43 characters long for a 32byte Ed25519 key. 32*8/6=42

That is because tor drops trailing '=' from base64 encoded values within descriptors. Some fields indicate this within the spec, others don't.

https://gitweb.torproject.org/stem.git/tree/stem/util/str_tools.py#n98

I'd like to use "ed25519 identity" or even just "identity" here going forward.

Gotcha. The name of 'identity' makes me wonder how this relates to relay fingerprints, which are the canonical identifier we use.

Regardless, the more we can standardize the terminology we use the less confusing these fields will be.

Cheers! -Damian

The way I understand it is this: Relay fingerprints are based on the RSA key, which will go away eventually. The canonical identifier will be the identity. We should start that transition

Thanks Sebastian. In that case we should put more thought into this because fingerprints are foundational to our control and directory specifications. Commands, events, descriptors... really everything reference relays by fingerprint (or optionally sometimes nickname). Migrating to a new identifier is no small task.

First, I'd advise that we call these 'v2 fingerprints' so it's clear that we intend to substitute these anywhere traditional fingerprints are used.

Second, I would advise against truncated base64 identifiers. Fingerprints are 40 character hex. master-key-ed25519's base64 value can include slashes (such as "yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI") which will be problematic for DirPort urls, GETINFO commands, etc.

The simplest solution would be to simply hexify these values. This will raise our fingerprint length from 40 to 64 characters which will slightly impact DirPorts [1], but otherwise I don't anticipate a problem with such a replacement.

============================================================

import base64

def hexify_id(ed25519_identifier): binary_id = base64.b64decode(ed25519_identifier + ((len(ed25519_identifier) % 4) * '=')) return bytes.hex(binary_id).upper()

identifier = 'yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI' print('the hex id of "%s" is "%s"' % (identifier, hexify_id(identifier)))

============================================================

% python3.7 demo.py the hex id of "yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI" is "CA9D1FC2DA7869AFD53326491B3F2F37B2A6DF361EB75601670A99124D42C072"

============================================================

Cheers! -Damian

[1] At most 96 server or extrainfo descriptors can be downloaded from DirPorts via their fingerprint due to a limitation on the url length by squid proxies...

https://gitweb.torproject.org/stem.git/commit/?id=871a957f

Maybe this is no longer relevant? If it is then raising the fingerprint length from 40 to 64 will reduce this maximum to 60 (which seems fine to me).

Isn't using "fingerprint" not a bit misleading since it is not the output of a hash function but the ed25519 master public key itself?

Hi nusenu, that's fair. We've begun to conflate a couple concepts here...

* Relay operators, controllers, DirPorts, etc all require a canonical relay identifier. They don't care how it's derived as long as it's unique to the relay.

* Relays publish a public ed25519 key. This is an implementation detail that isn't of interest to the above populations.

I'd advise against attempting to rename "fingerprint". That hasn't gone well for hidden services [1]. But with that aside, relay identifiers and the representation of ed25519 public keys don't necessarily need to be one and the same.

[1] https://trac.torproject.org/projects/tor/ticket/25918

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)

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?

Damian Johnson:

...

I hope we can agree to use the same format in all places.

Thanks nusenu, that's a great summary. Honestly I doubt that deprecating RSA keys is on anyone's visible horizon, and by extension RSA-based fingerprints will remain our canonical identifiers for the foreseeable future.

That is fine. To clarify: I'm _not_ aiming to speed the transition to a RSA1024 free tor world up (that is not my goal here). I'd just like to see a decision on the naming and format that will be used from the point the decision has been made - so I can point to it and use it in the well-known URI submission. If it is clear to you that we will not see a decision on the naming and format in Aug 2020. That is also valuable information for me.

On Tue, Aug 4, 2020 at 6:41 PM nusenu nusenu-lists@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

...

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.

thanks for the prompt reply.

Hm, ok I guess then we have already reached the point of no return where it is too late to come to a common format that can be used everywhere even in places where "/" is not supported.

kind regards, nusenu

submitted as: https://github.com/protocol-registries/well-known-uris/issues/8

@nickm and Mike: Mark would like to hear your opinion on it. https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment...

On Sat, Aug 8, 2020 at 3:37 AM nusenu nusenu-lists@riseup.net wrote:

submitted as: https://github.com/protocol-registries/well-known-uris/issues/8

@nickm and Mike: Mark would like to hear your opinion on it. https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment...

I think as a general idea this is fine. I could probably tweak the format a bit, but there probably isn't a strong need.

One thing I'd want to know about though, is current uptake and trends in uptake. How many relays are currently using this schema?

I'm happy to say "yes, this is a good thing for family operators to do" if that will help, but I'd rather that we only standardize something if it's on track to get used.

peace,