github.com/okex/exchain@v1.8.0/libs/tendermint/docs/tendermint-core/secure-p2p.md (about)

     1  ---
     2  order: 12
     3  ---
     4  
     5  # Secure P2P
     6  
     7  The Tendermint p2p protocol uses an authenticated encryption scheme
     8  based on the [Station-to-Station
     9  Protocol](https://en.wikipedia.org/wiki/Station-to-Station_protocol).
    10  
    11  Each peer generates an ED25519 key-pair to use as a persistent
    12  (long-term) id.
    13  
    14  When two peers establish a TCP connection, they first each generate an
    15  ephemeral X25519 key-pair to use for this session, and send each other
    16  their respective ephemeral public keys. This happens in the clear.
    17  
    18  They then each compute the shared secret, as done in a [diffie hellman
    19  key exhange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange).
    20  The shared secret is used as the symmetric key for the encryption algorithm.
    21  
    22  We then run [hkdf-sha256](https://en.wikipedia.org/wiki/HKDF) to expand the
    23  shared secret to generate a symmetric key for sending data,
    24  a symmetric key for receiving data,
    25  a challenge to authenticate the other party.
    26  One peer will send data with their sending key, and the other peer
    27  would decode it using their own receiving key.
    28  We must ensure that both parties don't try to use the same key as the sending
    29  key, and the same key as the receiving key, as in that case nothing can be
    30  decoded.
    31  To ensure this, the peer with the canonically smaller ephemeral pubkey
    32  uses the first key as their receiving key, and the second key as their sending key.
    33  If the peer has the canonically larger ephemeral pubkey, they do the reverse.
    34  
    35  Each peer also keeps a received message counter and sent message counter, both
    36  are initialized to zero.
    37  All future communication is encrypted using chacha20poly1305.
    38  The key used to send the message is the sending key, and the key used to decode
    39  the message is the receiving key.
    40  The nonce for chacha20poly1305 is the relevant message counter.
    41  It is critical that the message counter is incremented every time you send a
    42  message and every time you receive a message that decodes correctly.
    43  
    44  Each peer now signs the challenge with their persistent private key, and
    45  sends the other peer an AuthSigMsg, containing their persistent public
    46  key and the signature. On receiving an AuthSigMsg, the peer verifies the
    47  signature.
    48  
    49  The peers are now authenticated.
    50  
    51  The communication maintains Perfect Forward Secrecy, as
    52  the persistent key pair was not used for generating secrets - only for
    53  authenticating.
    54  
    55  ## Caveat
    56  
    57  This system is still vulnerable to a Man-In-The-Middle attack if the
    58  persistent public key of the remote node is not known in advance. The
    59  only way to mitigate this is with a public key authentication system,
    60  such as the Web-of-Trust or Certificate Authorities. In our case, we can
    61  use the blockchain itself as a certificate authority to ensure that we
    62  are connected to at least one validator.
    63  
    64  ## Config
    65  
    66  Authenticated encryption is enabled by default.
    67  
    68  ## Specification
    69  
    70  The full p2p specification can be found [here](https://docs.tendermint.com/master/spec/p2p/).
    71  
    72  ## Additional Reading
    73  
    74  - [Implementation](https://github.com/tendermint/tendermint/blob/64bae01d007b5bee0d0827ab53259ffd5910b4e6/p2p/conn/secret_connection.go#L47)
    75  - [Original STS paper by Whitfield Diffie, Paul C. van Oorschot and
    76    Michael J.
    77    Wiener](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.216.6107&rep=rep1&type=pdf)
    78  - [Further work on secret
    79    handshakes](https://dominictarr.github.io/secret-handshake-paper/shs.pdf)