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]
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
FWIW the correct link is: https://github.com/devnetsec/rand_num_consensus.
Georg
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]
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
And some email clients like mine even include the trailing "." in the link!
Third time's the charm: https://github.com/devnetsec/rand_num_consensus https://github.com/devnetsec/rand_num_consensus
On Tue Oct 22, 2024, 10:48 AM GMT, Georg Koppen mailto:gk@torproject.org wrote:
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
FWIW the correct link is: https://github.com/devnetsec/rand_num_consensus.
Georg
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]
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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
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
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.
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
On Tue, Oct 22, 2024, 4:15 PM stifle_savage042@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
On Tuesday, October 22nd, 2024 at 11:24 PM UTC, Watson Ladd wrote:
On Tue, Oct 22, 2024, 4:15 PM stifle_savage042@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
-
Georg Koppen -
Holmes Wilson -
stifle_savage042＠silomails.com -
Watson Ladd