When is the 'MyFamily' setting unnecessary?

[Robert Ransom]

On Sun, 12 Sep 2010 23:36:30 -0400
Gregory Maxwell <gmaxwell at gmail.com> wrote:

> 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?

No, the client needs to see it in the relay/bridge descriptor.

>                                                            (obviously
> they'd need to be left outside of the part signed by the nodes, so
> obviously some reworking is required there).

???

Why?

>                                              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.

I don't see how it could open up any *new* attacks -- the directory
authorities can already ignore relays, or mark them as Invalid, with
near impunity.

> 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)

Don't forget that the keys and signatures would need to be represented
in ASCII in the descriptors.  If you're willing to break backward
compatibility anyway, there is some room for squeezing the existing
family specifications down, as well (i.e. represent node identity key
fingerprints in base64, or even base85 (only the clients should care
about it, and they can probably eat the performance cost)).

Also, don't forget that we can use an elliptic curve modulo a 159-bit
prime for this -- node family keys are relatively low-value
authentication keys, and since they would only be used to sign nodes'
ephemeral *signing* keys, they can be changed with rather little trouble.


Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20100912/7ddce54a/attachment.pgp>