[tor-dev] Gosling onion-to-onion specifications

[Richard Pospesel]

Hi everyone!

tldr: Is there any reason why one should not use the same ed25519 public 
key to authenticate with multiple, unrelated ClientAuthV3 onion services?

----

Lots of progress has been made on building the foundation for Gosling 
over the past few months (rust/C FFI, cryptographic primitives 
integration, tor controller, etc) and I'm about to begin work actually 
implementing the protocol! The repo can be found here:

- https://github.com/blueprint-freespeech/gosling

The protocol spec (here for reference: 
https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md 
) calls for verified clients (ie 'friends' or 'contacts' in 
Ricochet-Refresh parlance) to connect to endpoints with v3 onion client 
authentication (see the 'request_endpoint' function in the 'Introduction 
Server RPC API' section).

Currently, the API is designed such that a client explicitly provides an 
ed25519 public key as part of the endpoint request to be used to encrypt 
their circuit descriptor (ie via the ClientAuthV3 param to ADD_ONION).

However, every client *already* has a public ed25519 public key 
associated with their identity; their onion service id associated with 
*their* introduction server (ie their own contact id in Ricochet-Refresh 
parlance). This public key is used in handshake verification to verify a 
client is who they say they are (see 'Proof Calculation and 
Verification' section).

Is there any particular reason why the client's identitying public key 
and the ClientAuthV3 public keys should be separate?

Being able to reuse this public key would simplify the protocol only a 
little bit, but if it means not needing to manage a key per contact that 
seems good. But if this is a terrible idea that's fine too. :)

best,
-Richard


On 12/4/21 14:51, Richard Pospesel wrote:
> Hi tor-dev,
> 
> As part of my work with Blueprint for Free Speech, I recently gave a 
> short presentation during the 2021 state-of-the-onion where we announced 
> Gosling ( see https://youtu.be/mNhIjtXuVzk?t=8155 ).
> 
> If you missed the talk, the tldr; is that we're developing a 
> specification and reference implementation library for building (onion 
> service based) anonymous+private+secure peer-to-peer applications.
> 
> Essentially, we're taking what we've learned about onion-to-onion 
> authentication from Ricochet-Refresh, extracting and improving the 
> relevant pieces, and packaging it all in a library that developers can 
> use to build their own anonymous+private+secure peer-to-peer 
> applications. Our hope is that future developers will not need to be tor 
> experts to build these types of applications.
> 
> Today ,I'm happy to announce that we just made the the gosling repo on 
> Github public!
> 
> - https://github.com/blueprint-freespeech/gosling
> 
> Things are little bare-bones at the moment, but the most relevant piece 
> right now is the protocol specification here:
> 
> - 
> https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md
> 
> You'll also find some initial prototyping work under the source 
> directory (the pace of development should pick up come 2022).
> 
> Please go take a look and feel free to respond here with any questions, 
> concerns, criticisms, etc. Thanks!
> 
> best,
> -Richard
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xDE47360363F34B2C.asc
Type: application/pgp-keys
Size: 5560 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220319/815b376a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20220319/815b376a/attachment.sig>