You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

73 lines
3.1 KiB

  1. Secure P2P
  2. ==========
  3. The Tendermint p2p protocol uses an authenticated encryption scheme
  4. based on the `Station-to-Station
  5. Protocol <https://en.wikipedia.org/wiki/Station-to-Station_protocol>`__.
  6. The implementation uses
  7. `golang's <https://godoc.org/golang.org/x/crypto/nacl/box>`__ `nacl
  8. box <http://nacl.cr.yp.to/box.html>`__ for the actual authenticated
  9. encryption algorithm.
  10. Each peer generates an ED25519 key-pair to use as a persistent
  11. (long-term) id.
  12. When two peers establish a TCP connection, they first each generate an
  13. ephemeral ED25519 key-pair to use for this session, and send each other
  14. their respective ephemeral public keys. This happens in the clear.
  15. They then each compute the shared secret. The shared secret is the
  16. multiplication of the peer's ephemeral private key by the other peer's
  17. ephemeral public key. The result is the same for both peers by the magic
  18. of `elliptic
  19. curves <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>`__.
  20. The shared secret is used as the symmetric key for the encryption
  21. algorithm.
  22. The two ephemeral public keys are sorted to establish a canonical order.
  23. Then a 24-byte nonce is generated by concatenating the public keys and
  24. hashing them with Ripemd160. Note Ripemd160 produces 20byte hashes, so
  25. the nonce ends with four 0s.
  26. The nonce is used to seed the encryption - it is critical that the same
  27. nonce never be used twice with the same private key. For convenience,
  28. the last bit of the nonce is flipped, giving us two nonces: one for
  29. encrypting our own messages, one for decrypting our peer's. Which ever
  30. peer has the higher public key uses the "bit-flipped" nonce for
  31. encryption.
  32. Now, a challenge is generated by concatenating the ephemeral public keys
  33. and taking the SHA256 hash.
  34. Each peer signs the challenge with their persistent private key, and
  35. sends the other peer an AuthSigMsg, containing their persistent public
  36. key and the signature. On receiving an AuthSigMsg, the peer verifies the
  37. signature.
  38. The peers are now authenticated.
  39. All future communications can now be encrypted using the shared secret
  40. and the generated nonces, where each nonce is incremented by one each
  41. time it is used. The communications maintain Perfect Forward Secrecy, as
  42. the persistent key pair was not used for generating secrets - only for
  43. authenticating.
  44. Caveat
  45. ------
  46. This system is still vulnerable to a Man-In-The-Middle attack if the
  47. persistent public key of the remote node is not known in advance. The
  48. only way to mitigate this is with a public key authentication system,
  49. such as the Web-of-Trust or Certificate Authorities. In our case, we can
  50. use the blockchain itself as a certificate authority to ensure that we
  51. are connected to at least one validator.
  52. Additional Reading
  53. ------------------
  54. - `Implementation <https://github.com/tendermint/go-p2p/blob/master/secret_connection.go#L49>`__
  55. - `Original STS paper by Whitfield Diffie, Paul C. van Oorschot and
  56. Michael J.
  57. Wiener <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf>`__
  58. - `Further work on secret
  59. handshakes <https://dominictarr.github.io/secret-handshake-paper/shs.pdf>`__