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/goslingThe 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/goslingThings 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.mdYou'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
Attachment:
OpenPGP_0xDE47360363F34B2C.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev