[tor-dev] Sharing Circuits Between Onion Servers and Clients

[stifle_savage042 at silomails.com]

On Tuesday, October 22nd, 2024 at 9:04 PM UTC, Watson Ladd wrote:

> On Tue, Oct 22, 2024 at 3:47 AM stifle_savage042--- via tor-dev
> tor-dev at lists.torproject.org wrote:
>
> > Hi all,
> >
> > I want to promote some recent work of mine in the hope that someone here will find it interesting or useful. In my most concise language, it is a "decentralized, asynchronous entropy generator protocol." I've made a somewhat complete demo implementation so far. Here's the repository: https://github.com/devnetsec/rand-num-consensus. The integrity of the entropy can only be compromised if all nodes in the ring are malicious and coinciding. Currently, a Tor client cannot anonymously connect to an onion service by directly contacting the rendezvous point, because that relay could have been chosen maliciously by the onion server. I wager that a scheme like this could enable onion servers and clients to share the same circuit. Both parties would have a guarantee that their relays were chosen randomly.
> >
> > The most similar solution I could find to this was in the TorCoin paper, but it appears to require a more complicated zero-knowledge proof. If there is serious interest in this, I'd be willing to write a proposal draft. Besides implementation difficulty, is there any outstanding flaw in this idea?
>
>
> Uh, yes. Depending on how we class implementation difficulty.
> - A node can go offline before revealing to influence the random
> choice. This is very hard to deal with in general.
> - Encryption isn't a commitment, particularly not with AES-GCM
>

I don't think my README explanation is quite clear enough. The purpose of encrypting "blocks" is to allow each node to be confident that its peers cannot manipulate the consensus in a way that jeopardizes its randomness (I suppose the consensus can be manipulated, but the result would still be random). It's as if a group of people each secretly write down a number 0 through n on a slip of paper, put those slips in a hat, then publicly sum these numbers once enough people have added their slips, and consider the remainder of that sum, when divided by n, the consensus. Then they can each truthfully testify that the consensus is random, so long as they are confident in the randomness of their own random number. A participant would have to know all the numbers their peers chose to successfully make the consensus equal the malicious target value. If a node is offline during the routine, the client will simply see one less signature on the consensus. I partially agree with your first point though. Currently, a node can stall the consensus by refusing to publish its reveal key.

I apologize for that broken link.

Dylan Downey [devnetsec]

> Sincerely,
> Watson Ladd
>
> > Best Regards,
> >
> > Dylan Downey [devnetsec]
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>
>
> --
> Astra mortemque praestare gradatim
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: signature.asc
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241022/cc5b1a19/attachment-0001.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gpg.key
Type: application/octet-stream
Size: 664 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241022/cc5b1a19/attachment-0001.obj>