Verifiably unpredictable ids (revised)

[rendaw]

To continue our conversation from the previous ticket,

I'd be interested in seeing what some other projects are doing. In my project, I sign the values and include a hash of the signing key's fingerprint in the key.

However, without changes at the protocol level it's still possible for malicious entities to intercept traffic. If an application signs and validates values then a hostile node can't forge data, but it can deny the existence of data which is enough to censor the network.

This patch changes node ID generation and adding to the routing table.

Each node creates a secret value (the seed). From that, it creates a private signing key and a public verification key. The node's ID is (hash of the verification key, the verification key).

When the local node encounters a new remote node, it sends a challenge message (random) to the new node. The new node signs the challenge and sends the signature. The local node validates the signature before adding the node to its routing table.

This serves two functions. As with the previous patch, because the ID value used for routing is a hash, a malicious entity cannot choose it freely, say, to match the key of a known value. Secondly, completing the challenge to new nodes requires knowledge of the secret key, so a malicious entity couldn't craft a node to impersonate another known node.

This is a significant departure from the original paper so I'd understand if it's not the sort of thing you want to include here. I think censorship is a concern for many use cases though, so it may be of practical interest.

And, as with the previous patch, I'm not a security expert so please take this with a grain of salt.

[bmuller]

Thanks @rendaw! I'll take a look when I get a chance.

[bmuller]

Been a long while, but I finally had a chance to look at these suggestions. I think at this point the library is flexible enough that many of these could be implemented at the storage level (via a custom storage class, which the lib supports). In the aggregate, I think that functionality could exist as a separate library that uses this one to add unpredictable ids. Please feel free to reopen if you still see a need and want to discuss. Thanks!