avoiding frequent MyFamily syncing on a dynamic Tor instance group
Hi, I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes: To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones.
From a security point of view this is probably quite a bad thing, but does someone already do that?
Sounds like a great idea to me. On 07.04.2011 01:36, tagnaq wrote:
Hi,
I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes:
To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones.
From a security point of view this is probably quite a bad thing, but does someone already do that?
-- Moritz Bartl https://www.torservers.net/
On Thu, 07 Apr 2011 01:36:55 +0200 tagnaq <tagnaq@gmail.com> wrote:
I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes:
To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones.
From a security point of view this is probably quite a bad thing, but does someone already do that?
If you handle the secret keys sensibly, it won't harm security, but the extra (not-yet-in-use) MyFamily entries will take up more space in your relay descriptor than necessary, and thus use more of the Tor network's bandwidth than necessary. Robert Ransom
On Wednesday 06 April 2011 19:36:55 tagnaq wrote:
Hi,
I don't know if this is already done but it just came into my mind when writing something to sync MyFamily settings throughout multiple nodes:
To avoid frequent reloads of many Tor instances, one could pre-emptively create keys (lets say keys for 30 nodes) and build a MyFamily set for it. As you add nodes use this MyFamily set although not all 30 keys are in use yet. This way one would not have to touch running instances when adding new ones.
What happens if relay A declares relay B to be in its family, but B does not declare A? Or if A declares B, B declares C, C declares D, and D declares A? There are a few ways to handle large families without bloating relay descriptors: 1. All relays in a family declare MyFamily to be a single ID, which could be, but doesn't have to be, the ID of one of the relays. A declaring B and B declaring A are equivalent. Two relays M and P are in the same family iff there is any chain of relays (up or not) beginning with M and ending with P such that, for all pairs of adjacent relays, at least one declares the other to be in its family. Since all relays in a family declare the same relay to be their family, this chain has length at most 2. 2. If A declares B to be in its family, but B does not declare A and there is no chain from B to A, then A will not be followed by B in the circuit, but B may be followed by A. 3. If A declares B to be in its family, A and B will not appear together in a circuit, in either order. But if A declares B, B declares C, C declares D, and D declares A, then A and C may appear together. What does the program actually do? cmeclax
On 04/07/2011 04:24 AM, cmeclax-sazri wrote:
What does the program actually do?
To my understanding only mutual agreements result in a valid MyFamily set. Unidirectional definitions would result in certain attacks. (this has been discussed on tor-talk a while ago) rransom, thanks for the explanation regarding the effect on the descriptor size. tagnaq
participants (4)
-
cmeclax-sazri -
Moritz Bartl -
Robert Ransom -
tagnaq