On Mon, Sep 13, 2010 at 12:11 AM, Robert Ransom <rransom.8...@gmail.com> wrote: >> 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. >> they'd need to be left outside of the part signed by the nodes, so >> obviously some reworking is required there). > Why?
The client needs to see the public key for sure, since thats effectively a family ID. Does it need to see the signature if instead it trusts the bridges to have validated the signatures and correctly ignored/invalidated only and all the nodes with invalid signatures? If that was workable it would halve the amount of advertised data required. > 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)). I was assuming hex, like the current families. 512/160=3.2 Obviously base>16 would do even better... With smaller ecc and base85 it would be rather close in size to the existing fingerprints. (assuming the signature was omitted) > 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. Agreed, that they can be small. Though changing them would require per-node configuration. They ought to at least be strong enough to discourage mischief, though 159-bit is still harder than anything that I'm aware of being cracked and would probably leave guessing the secret as the low hanging fruit. *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/