[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses
Michael Rogers
michael at briarproject.org
Tue Feb 7 10:33:25 UTC 2017
On 05/02/17 07:44, Taylor R Campbell wrote:
>> Date: Sat, 04 Feb 2017 20:14:00 -0600
>> From: Vi Grey <vigrey at riseup.net>
>> Also, should we consider including a Version option eventually in the
>> ADD_ONION control port command when using a KeyBlob? It wouldn't matter
>> much for this new version and probably wouldn't matter much for a while,
>> but it might be good to keep this in mind for the future.
>
> Versioning onion addresses and versioning network-internal service
> descriptors need not be done the same way.
>
> Addresses are likely to be long-term, and should really change only if
> the meaning of the encoded public key has changed incompatibly but
> otherwise imperceptibly -- e.g., if for some reason Tor switched from
> Edwards coordinates to Montgomery coordinates on Curve25519. (That
> would be a silly thing to do -- it is just an example of a change that
> could still interpret existing addresses, but differently.)
It seems to me that different people in this thread have different ideas
about what the version number in the onion address represents, and it
would be good to make that explicit in the spec. Does it represent:
1. The version of the *onion address format* - meaning that, for
example, a v4 address and a v5 address could point to the same
descriptor, which would be compatible with both addresses?
2. The version of the *descriptor format* - meaning that a v4 address
must point to a v4 descriptor, but a v4 descriptor and a v5 descriptor
could point to the same hidden service, which would be compatible with
both descriptors?
3. The version of the *entire protocol* - meaning that a v4 address must
point to a v4 descriptor, which must point to a v4 hidden service?
Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170207/3e8fd8c9/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170207/3e8fd8c9/attachment.sig>
More information about the tor-dev
mailing list