When is the 'MyFamily' setting unnecessary?

Gregory Maxwell gmaxwell at gmail.com
Mon Sep 13 03:36:30 UTC 2010


On Sun, Sep 12, 2010 at 9:40 PM, Robert Ransom <rransom.8774 at gmail.com> wrote:
> That's the wrong approach.  The config file should contain a random
> secret key shared among all relays in a family, and the relays should
> publish in their descriptors a public key derived from that secret key
> along with a signature of the relay's current signing key with that
> secret key.  With DJB's Curve25519 elliptic-curve parameters, the
> public key can take only 511 bits, and the signature can take only 506
> bits.  A smaller curve could fit the public key into 319 bits and the
> signature into about 320 bits (the precise size would be determined by
> the group order).
>
> This would not be backward-compatible with existing clients, but it
> avoids the current quadratic blowup in both the config files and the
> total descriptor size.

There we go—

Perhaps the signature could be shipped only to the directory
authorities but left out of the published descriptors, no? (obviously
they'd need to be left outside of the part signed by the nodes, so
obviously some reworking is required there). Directories would ignore
nodes that claim families that they can't back up with a valid
signature. This would open up some attacks by a conspiracy of evil
directories but it would be detectable and no worse than other kinds
of attacks available to similarly compromised directories.

With the signatures left out of the descriptor and 511 bit keys the
break-even point for descriptor size is four nodes in a family.  A
very quick check with my cached descriptor data locally suggests that
this would reduce the aggregate descriptor size significantly compared
to the current scheme.  (there are enough families with _many_ nodes,
to offset the fact that most families are small)

Making families more scalable would also admit things like semi-public
families.  E.g. you could share a family key with all the node
operators in a common building. Detecting things like same network can
be done automatically with enough reliability, likewise for very
coarse geographies, but fine geographical configuration would take
manual intervention... I don't know if anyone would bother configuring
this, but it would be nice if the system scaled well enough to support
it.
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list