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@xxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > > > -- > Astra mortemque praestare gradatim
-----BEGIN PGP MESSAGE----- owGVVl2IJUcVnvw9ZEQIGhZRhOMgrDH33lkmA+KAq5PZJTuQJWazIQ8Slrrdp7sr t7qqp6r63vSKKIiQvIWIICIYiI+C5CEJInkIxBXiYx7y5kN8chH0LQ8K+p2qvndm QhTcgeV2d9Wpc77vO9+pVz5739b2hWsnx+/96qGjnXv+dHe+VX9h9zdPWbrZcyjV MKGniujm7Glvz5YT2ru0t08q0jcPLu3Td6/TszePJvScisFZelKVJa28i3ywvX2Z cpAUAJtPtz52sP+Nj37028PrFKKuDN8KaqlqvrS/N51OaakVReenJS8RY/z1HaND DDM8dd69wEWcOV+vj7qMdZfpmiZlzER+p+djWikbEYCwpcVCCq5l8lwwXq+cX5Cr qNWWSVuKDVPjOsYPZCgrHT407JlW2hiqtC1JRyyNeIe8bU3OUx+46s2Mji21A7Uu RCqcLXRgMsrWPcqapG2BFO2U6WyvjL7NgFKFwRaNd9b1geSD6waq2bJXKFTSjq5w ZrZDxxeXTK0qGVEkt5UkWbi2M4y6Sm4daXloEUVFDSqCo0r5GV1DthdDKs9z54JG 5OGAmhi7cLC7W+vY9PMZQu0CZcsxcLHrlS2ntm+nKCWwDX2Y0c2GU+2113EQ4CTi OudCWXLWDDTnlBXwBgLAqxJKyLqSwxpkL8gpL+UYXWgpHcdhmwZsJT7O6Kj3HqEN tKfoJpAojBbOcIx1EcudHVpsxIHI0EINwnLKIZXOfqkLpvlApQbdMa+LqkisZShs ybeXcniHg+MEmRcKZGb6PRsle3pTUqMA/ZzZUtE4oHGat9Q7pHCn5zIgF+HV6JcU CnwVDXghoxcSHULIcdmquTm/dUQiFRukpNAIUHJCUAhRaF/0Os7ocRcb6pSPGriu TtNUBMWBvchjIdiqfS4HC0XMYxFCsWvNMNu0ixAs+r1LQbfaKA8JmT5p6XhMOfUA 0kpVrNSGUlB0BBSRUcceUPZRJK+6jpVPdXg+6cEE8mudzxIBhipCIrfZu+nCupXh smbRvKsAYdIXluIgYJNUsu68fKoOE3RFKYqT/kzEOhiCjnIMwkDrylDpVSWAcdBJ g+ebpNRVpYveRChNh/FIZaHvPoYIiCRsZdRqfSYhivq2GA4we7aZ0MDojSvccV6L mI1bAWmwqML/OE9wn9Jhao3UPrVDU1VG3GjOlaDkeclqXZi2lenZFlkNmT2EAJtQ unSn5BYIIhogBZ9oQqoG4EAqyD7bisnnXrWFH7qUkg72oqgUnLQ6SqqTrCykqTwk Lh2XghxefWb6xNF1lL59TKWTbYDELsT4blw9vHL9KvGLHVxPjYEJpEdBAjKA3F1f N9lHut6DHRYX4TETVLkzN65YhJ3EhBPjAJKsiiaDhFfJXWwFDsTXRd8afdKxdM7o Da2yukPmMQO1MTCBQEGzQ973AjsUWcKGQ4qRAbUMyr52TKHvUn7nIwhLcz5zQpml nv0kgNWxFTEcYHrzNU2PQM4RFiz9UkmLetd3UnuHJOAAqUTYrmcxqqzg0q0kX3iw DN5LOMMLfCQWJ5ZidI6QG65LWUjG8mGsFWVOJDe0ZT9HtyF26Ft5g3U5cEC0gkdq 1uk0f01OUpZozmwfKehkdGkrjeTHolsFR8BTGgcyNvt2Qis5s9RLLRFgkHZyHsik gWQceXCk+qPvY4NJiiyjTNdq2BjYWRLXTE1kvhknkyTkSMqfFcd61pzSmicWqhFk 8/sRhRnaMCted8rGs34KzYk1pSEm8daw5Uij8BLwYtZ9UeCkXESrFp/UDzxQ5TCn ky8qX3OkpUJzJ9dTWew6bNyg7P1masGW8GrEM8/EdDkJ4jPgl2WeYNRIwUHX6MTe y6tPEnCcC1aSqao9c+7wwfUeJv/u5z1cNs1FkVVq23MjeWNa8MgRmdMywbjHnSiM xpXEF5rcZcnRaMGwP3iI6pxxNXqQ4HeZ7rl3C2gDhS+w5MoAN6ErYAwEf29zP3le 7pbP4LoAt0ZCeDhz/Rwvg4/LoLjBNZo8nF4J/2tA+Xjr//uX9oy3UzCqk1PLLfXs h0+9tqYF6wvYpy3YLWo9nWu7K2HhN2kRJoDb3dyL1380neK/w4BLpczWyO1JL1NU oX5pidqrEn7cbr/U3791YXvryxe+cv+LXz3pX37yWw/+44//emt98X/gXrn1b20/ +ND6zffvbv1bvbb85bU7P3/s5P0bz/3hB39558P3X//ZT179/Qd3Vv7jv3/mlR/f s3Xnh1/80tu//umF/V+89PEH9/7z6Udvvfb1v73xxNHR795++M0/f+6+/wA= =Mw/Z -----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