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

stifle_savage042--- via tor-dev Tue, 29 Oct 2024 01:05:37 -0700

On Tuesday, October 22nd, 2024 at 11:24 PM UTC, Watson Ladd wrote:
>
>
> On Tue, Oct 22, 2024, 4:15 PM <stifle_savage...@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@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.
>
>


The commitment isn't the encryption of the random number, it's the signature on 
that ciphertext.
See message::Block. The AES-GCM nonce makes sure that decryption fails if the 
incorrect reveal key is used.
That's what I'm guessing you mean by "commitment," can you explain a bit more?

Dylan Downey [devnetsec]

> I apologize for that broken link.
>
> Dylan Downey [devnetsec]
>
> > Sincerely,
> > Watson Ladd
> >
> > > Best Regards,
> > >
> > > Dylan Downey [devnetsec]
> > > _______________________________________________
> > > tor-dev mailing list
> > > tor-dev@lists.torproject.org
> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
> >
> >
> >
> > --
> > Astra mortemque praestare gradatim
>

gpg.key
Description: Binary data

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

Reply via email to