Re: [tor-dev] How do Ed25519 relay IDs look like?
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 -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] How do Ed25519 relay IDs look like?
On Sun, Oct 10, 2021 at 5:13 PM nusenu wrote: > > > On Tue, Aug 4, 2020 at 6:41 PM nusenu 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] How do Ed25519 relay IDs look like?
On Tue, Aug 4, 2020 at 6:41 PM nusenu 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor Prometheus Metrics Documentation
Hi,
since Neel is working on unix socket support [1] for MetricsPort
I'm preparing to add support for it to relayor.
I don't like to add additional attack surface to a relay but since
tor does not support TLS and basic auth on the MetricsPort I'll likely
install nginx that takes care of TLS and authentication.
If you have any opinion on that I'd also like to hear it.
It would be nice to have a documentation for all tor prometheus metrics
in the man page or on a website, some information can be found at [3] but not
all.
Is there already a complete documentation for tor prometheus metrics data?
Here is an example of how other projects have documented their metrics [5].
I don't know if it is too late for that but it would be great to use the
well known IANA RCODE [4] naming for the DNS return codes
where possible instead of the custom naming.
examples (just guessing):
tor_relay_exit_dns_error_total{... reason="format"}-> FormErr?
tor_relay_exit_dns_error_total{... reason="notexist"} -> NXDomain?
kind regards,
nusenu
[1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/453
[3] https://support.torproject.org/relay-operators/relay-bridge-overloaded/
[4]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[5] https://doc.powerdns.com/recursor/metrics.html#metricnames
related feature request:
[2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40194
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id
nusenu: cut -b 33- ed25519_master_id_public_key |base64 hint: don't use this Since cut is line based it will only read until the end of the line but the input file is not a text file - so it will stop reading at random offsets. -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 335: An authority-only design for MiddleOnly
Hi, has this proposal any implications wrt to making the MiddleOnly feature available to clients (without requiring DA actions)? With ExcludeExitNodes/ExitNodes + ExcludeGuardNodes [1] tor clients basically can get the "MiddleOnly" feature without DA actions, but ExcludeGuardNodes [1] is not there yet. This is why I'm asking. [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436 ## Generating votes When voting for a relay with the `MiddleOnly` flag, an authority should set all flags indicating that a relay is unusable for a particular purpose, and against all flags indicating that the relay is usable for a particular position. This part was not clear to me, but if I ignore it, the rest makes sense. It is not clear because it says an authority should set _all_ flags to indicate that a relay is unusable for a particular purpose. kind regards, nusenu -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id
Yes, there is! First you verify that the file is really 64 bytes long, and that the first 32 bytes of the file are really "== ed25519v1-public: type0 ==\0\0\0". Having done that, you base64-encode the second 32 bytes of the file, with no "=" padding. thank you for this description, so I can confirm that this: cut -b 33- ed25519_master_id_public_key |base64 gives me the same string as in the file fingerprint-ed25519 kind regards, nusenu -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id
On Sun, Oct 10, 2021 at 8:44 AM nusenu wrote:
>
> Hi,
>
> given a relay's ed25519_master_id_public_key
> file, is there a simple way to generate the
> 43 chars long ed25519 identity string (also found in fingerprint-ed25519)?
>
Yes, there is!
First you verify that the file is really 64 bytes long, and that the
first 32 bytes of the file are really "== ed25519v1-public: type0
==\0\0\0".
Having done that, you base64-encode the second 32 bytes of the file,
with no "=" padding.
I've attached a lazy little python script.
cheers,
--
Nick
#!/usr/bin/python
import sys
import binascii
# requires python 3
assert sys.version_info >= (3,0,0)
try:
s = open(sys.argv[1], "rb").read()
except IndexError:
print("Syntax: {} ".format(sys.argv[0]))
sys.exit(1)
header = b"== ed25519v1-public: type0 ==\0\0\0"
if len(s) != 64 and s[:32] != header:
print("This wasn't an ed25519_master_id_public_key file.")
sys.exit(1)
else:
print(binascii.b2a_base64(s[32:]).decode("ascii").strip().replace("=",""))
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] ed25519_master_id_public_key -> ed25519 id
Hi, given a relay's ed25519_master_id_public_key file, is there a simple way to generate the 43 chars long ed25519 identity string (also found in fingerprint-ed25519)? thanks, nusenu -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
