[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Sharing Circuits Between Onion Servers and Clients
On Tuesday, October 22nd, 2024 at 11:24 PM UTC, Watson Ladd 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
> >
> > > 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
> >
> >
> >
> >
> > --
> > Astra mortemque praestare gradatim
>
-----BEGIN PGP MESSAGE-----
owGNV8+LJEkV7nHXwxSIi4c5CAvPZmEUqqp72hGx1J7t6Wl3CnZY2elFUWSJynyZ
GVuZETkRkV1T4x4ERXRB8A8QlMWreBEvelDYZQ7iXeameFEPzsWbsH4vIutHt72O
1Yeuyox4P773ve9F/Phjz+0Mrt19MH3vpy8c7175w99nO+WLt/76mqHTjn2ulkN6
LQt2xo4ODkw+pIP9g5ukAt24McGXr96jN06Ph/Q1Fbw19KrKc1o4G3gyOJQ/Soai
ERhI24d0c3Ljc3/5zi+x+0s+6KLmN706UyXv3zx42evaNkrXfpzZ5nDLGsnn2YF9
YbL/rLiipctjEwufndz8PKI7ukcXgxuNRnSmFQXrRjmfrS31v1+utQ9+jF+ts29x
FsbWlWu/ae16zyHd1aTqerh5svVuSgtlAgwTTDUwQN42TI4zxuOFdXOyBTXaMGlD
oWKqbMv4gvhlpcWLih3TQtc1FdrkpAOWBjxDVqYk66jzXHT1mKaGmiU11gfKrMm0
Z6qVKTskPYzbPCnazaNvp2r9iIG38kuTVc4a23mSF7ZdUsmGnQIAEnawma3HuzS9
fsbUqJxhRWJbSJAoblsz8sq5saTlRwMrKmjUy1sqlBvTXUR73cf0HLfWa1heTqgK
ofWTvb1Sh6qbCU/2gL7h4Dnbc8rkI9M1I6Ti2fjOj+m04ph76XRYCnBicRVzpgxZ
Uy9pxjEq4A0EgFch5SFjc/YrkJ0gp5ykU+tMS+pwh20asOV4OabjzjmYrkFQRadA
Iqu11AxujA1Ybs2ywUY4RIQGLJEqxxhi6uzOdMY0W1KuUe6Q1gWVxaolKEzOj87E
eQvHYYjIM4VipvI7rpXs6eqcKgXoZ8yGssoCjU3cku8ymtv4ZUD+D2Feia6KtlCw
rEJhqNZzMQ8mJMNs1Kw+v7eHImbrJSdfCVLiwiuYyLTLOh3GdNuGilrlggawi02c
ikA5lC9wnwm2apfywUJhc5+F1Ng29XJ8ae9ItSOZvW50rRzoVHeRV9M++tgPiDAm
tFDr8qJcx0AUwbXsAGsXhP6qbVm5mJLjBx2qglAb6xJdgKcKoMsjdnY0N3ZRc16y
8N8WaK3INSyFI8AUGbPqwuRV+yE6JBf2Sa/GIluIhg7iBmbAe1VT7lQh2LHXkY/n
GybXRaGzrg5gnfa9S2XA9S74ALTEbFGrxconwYq6dVGU1iC+UQ1pyeicO9xy2g0v
lV2gDCix8v8jgk1RRnQU2ye2WGnReEUtijXjQtBzfMZqlbA2Rd2xyRJhUoHXhlB2
9IT0sUTuCWxbgjMuFhGJ1IAOnEJuSYDq7RhOTOaWbQxSe3NdSI26NTpI8MNERASu
HFpCOjSaOjq5P3rl+N4GmP7blHIrNoChmYtqvn5ydOfeCfHDFpKpei8ElgQBCrxB
q9iurJIItZ1DOVkkiPuwkP7urLbZ3O/G0llRHQDNKqsSengUpckUKJoMBekNjR5r
WbquF5ZGGd0ijZAQXKufoKJA8mXa9xZbZJxDw320kZA2jIp+ekq+a2N85y1I+Wa8
5SFPvZHEyKPofRtjskAxZ6v6fQb8D9BvabBC2tvZrpXcWwQB9YgpQrMdi8olyud2
IfFCwGW078OHE/hI9FHkqNbJQurQNkYhEcuLPlekOZTY0MfdDO0J275r5AnWJcMe
1jLuS7MKJ4lQnqOZk/JEm8Ne4Y00nutzxgHFyK84SmTkds2QFuIy12daLEBczfA8
jpECUWjS0InpB9eFClMYQQaZzMVyrX3bNVwVaiizsbYyhXyypNw2N1ZzalPVNO2Q
jQCbnvcgjNGeif26VSZsSzEoJ1IWB6DYW6GWLPW8i7iLzndZBk8piUbNL9IHmqmS
mc3UDMqVHOhMoemjSqrEde3XKpF3bj3xIGN41OOZ5mk82HhRIZSXZRRhSknCXpdo
xM7Jo4sFmKaElUSqSsecun1pO4eh4KDJcaIKp2LPnhvmaymDova4bJJEvR1OU76X
s8g8X6UWizpHcxZpjErSq4tkK62b5CjE48Npkm45YiAZTGKf+ND3IA5hohpC0YWN
ossuohFHpOSyeQaHPnkcDE5jsCvV64UwnYLW6piY8rfzJJEDYH8EuwCsBKVbhBv4
YRgP7vM65MnktghakrxVriZ2nNADJepcP+L7fMR9IYd+EYoQT2uZdXL82UJP4MIp
Jx8jGyVBxYPk9HqDcwMcC/IoJIIQqJa0u6XyuxE/eRuFOsrEDKNdpvitweDOEuJN
d9Ah8PLN9VnyWwBuJfuqtbUtIZuE2ZVinzk7Rz+DrPPxekB8qKnNcL2P5FAhkGr9
aOuecslF4bYcFl7nErrtL78ufLjX9ZI3/9/P70bp/9be/n5Dci8TmOWe89+vL73+
bC1bHdsvW7aXlXo002ZPXGDQxEU4E9i9C3etZ/2n0Wj99cjjuiI1Dtw86ORMpoCk
9FbpVI5hjRPG4Afd8zvXBjsvXvvU8w9fetD98NUvX336+N+/Xl2JP/oRuQ/vDK6+
sHryjcMrO9+/+87vv3dCH9/5c/He7DePv/3uk39+5e3pj/70i5f+9e4Xf3X16zsf
vP3z7z5559DvX3n/J+9/UP32Z59UT58+md96/PjRH/Ur2See+w8=
=d5Nx
-----END PGP MESSAGE-----
Attachment:
gpg.key
Description: Binary data
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev