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