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

[Watson Ladd]

On Tue, Oct 22, 2024, 4:15 PM <stifle_savage042 at silomails.com> wrote:

> 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.


AES-GCM is not committing. There are messages that can be decrypted two
different ways with different keys.


> 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 HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241022/7865c3f8/attachment.htm>