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

stifle_savage042 at silomails.com stifle_savage042 at silomails.com
Tue Oct 22 02:48:32 UTC 2024


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?

Best Regards,
Dylan Downey [devnetsec]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241022/905f80f4/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: signature.asc
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20241022/905f80f4/attachment.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/905f80f4/attachment.obj>


More information about the tor-dev mailing list