[NKP-0005] Hop by hop encryption

[yilun]

Currently all node-node and client-node traffic are not encrypted. We don’t consider this as a critical issue because:

1. Client to client messages are end to end encrypted
2. Most node to node messages are signed
3. Node to node messages do not contain any info that are not publicly available

However, it’s still beneficial if node-node and client-node messages are encrypted to enhance privacy & more.

Since every node and client has a Ed25519 pk, hop by hop encryption can be easily done using a shared secret key derived sender and receiver’s key. Even better, there are already well implemented and tested libraries (e.g. NaCl/libsodium) in all major languages so it’s quite easy to do it.

I’ve the performance of NaCl (golang.org/x/crypto/nacl) using one core:
Macbook Pro:

Raspberry Pi Zero W:

Basically we can do 100k+ or 10+MB/s msg encryption or decryption even on a small raspberry pi zero w, which shouldn’t be the performance bottleneck. (I skipped nacl/box because key derivation only needs to be done once per neighbor)

Another option is to use TLS with Ed25519 public key. This is a more native (and lower level) solution, but it’s not supported in Golang yet. AFAIK the current schedule is to support it in Go 1.13 or later. We need to investigate more to see whether we can use it (e.g. by using the latest Golang repo instead of release).

It’d be good to discuss here about other thoughts or concerns.

[yilun]

I don’t think TLS is a good option for us. @Moore

For TLS to work, each node needs to create his own certificate using his private key, and the certificate is needed for other node to connect to it. Assume node A wants to connect to node B, A needs to know B’s certificate somehow since A cannot compute it solely based on B’s public key. The problem is, how should A get B’s certificate? Some straightforward solutions are: putting the certificate on chain when each node generate his id, or making a json rpc before establishing p2p connection to get the certificate (less secure). Both need some extra steps and are not perfect: the first one is not available to nodes who don’t have block history, while the second one cannot guarantee the security of rpc call.

On the other hand, the most significant security benefit of TLS certificate is preventing MITM attack, which is already solved in NKN by having a one to one relation between pk and id stored on chain. As long as the attacker between A and B does not have access to B’s private key, A will never send any message that is intended to be sent to B to the attacker.

So in short, I don’t see any significant benefit of using TLS.

[Moore]

Agree.
p2p negotiate about symmetric encrypt suits just only depend on peer’s pubKey, certificate is unnecessary.

[yilun]

Implemented in https://github.com/nknorg/nkn/pull/512

[yilun]

This NKP has been implemented