On Sun, 12 Sep 2010 20:28:33 -0400 Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote: > 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. 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. Robert Ransom
Attachment:
signature.asc
Description: PGP signature