On Sun, 12 Sep 2010 23:36:30 -0400 Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote: > On Sun, Sep 12, 2010 at 9:40 PM, Robert Ransom <rransom.8774@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature