On Sun, Sep 12, 2010 at 6:53 PM, <and...@torproject.org> wrote: > On Sun, Sep 12, 2010 at 02:38:18PM +0200, tor...@ymail.com wrote 1.1K bytes > in 31 lines about: >> If it is technically not necessary, because tor would never use certain >> nodes in one circuit. I would understand people running >20 nodes that >> do not use 'MyFamily'. > > It's easy, put all 20 nodes in the MyFamily line and just use that line > for all 20 nodes. > >> If there are certain rules I would stop asking people to set MyFamily if >> one of these rules apply in the concrete scenario. >> >> So there are no rules beside the "/16 network" - rule? > > Perhaps it depends on what you mean by "rule". The /16 network > diversity is in the tor source code. There are other proposals in the > mix for circuits to contain a unique AS and/or a unique continent per > node.
A unique AS would be a much better restriction than unique /16... unique /16 is really just a weak proxy for unique AS. Even ignoring the other useful disclosure properties of myfamily you shouldn't skip disclosing the family even if the nodes are in the same /16 simply because that restriction may be replaced with another one (e.g. same ASN) in the future. It is a bit unfortunate that myfamily adds a fair bit of configuration load (N^2) as the number of nodes becomes large, it's especially annoying if you slowly add nodes to a family since you have to go back and hit the all the other configurations for every node you add. Has anyone previously suggested using a shared secret for family configuration? The protocol might look something like this: The user configures a secret per family which the node is a member of. For each family the secret is processed with key strengthening (such as PBKDF2 or, better, scrypt) and a (say) 64-bit family ID and a 128-bit family-key are derived. Nodes publish the family IDs. Upon discovering a new node with a common family ID the node contacts the matching node and uses the non-advertised family key in a handshake (this could be a zero knowledge protocol like socialist millionaires or just encrypting a concatenation of nodeIDs and nonces) to prove that the key is shared. After proving the secret is really shared the nodes store the results and update their family advertisements. This would simplify family configuration down to setting a single common secret string per family but wouldn't create any change in behaviour for non-family nodes and could also exist side by side with the old mechanism. *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
