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. > 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
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
