Document second handshake process in README

[kaloudis]

Need to come up with a digestible explanation for this in the README and perhaps for docs.lightning.engineering too

• First connection requires a pairing phrase
• Subsequent connections do not require pairing phrase because the keys will be fetched from storage
• Password is always needed

cc @Liongrass

[levmi]

This is what we have from previously:

Initial handshake
The Noise Protocol Framework is already used in the Lightning Network to handle encrypted connections between nodes (see BOLT 8 for details). It leverages the existing public keys that identify Lightning nodes and avoid introducing new complexity or dependencies and does not rely on certificate authorities.

The Noise handshake however is handled differently. The process is initiated by the user generating the pairing phrase in the Lightning Terminal Daemon (litd) as described above. This triggers the generation of a long-term public key for the handshakes in addition to the 64-byte stream ID.

The password-authenticated key exchange (PAKE) is combined in a single step with the Noise handshake. Through it, Lightning Node Connect and the application learn about the other side’s long-term Diffie-Hellman (DH) key and a shared secret, from which other keys can be derived.

LNC will only allow a single attempt to authenticate this key exchange, which allows the mechanism to make use of a low-entropy password that can be more easily typed or remembered.

The user enters the pairing phase into their application, completing the initial handshake. Lightning Node Connect can now forget the pairing phrase and will only communicate using the negotiated keys, preventing brute force attacks.

At this stage, instead of transmitting a zero-value AEAD payload, Lightning Node Connect may also pass a newly baked macaroon to the client, restricting access to the Lightning node, for example by duration, types of actions taken or amount of value being transferred. While only a single pairing phrase may be generated at a time, it is possible to maintain multiple connections with their unique DH key and macaroon, for example for different types of applications or users.

The handshake variant used in LNC for the initial connection:
XXeke_secp256k1+SPAKE2_CHACHAPOLY1305_SHA256
Secondary pairing handshake
For each subsequent connection LNC performs a secondary pairing handshake., In this second handshake, the key authentication can be omitted, as long as the long-term DH key is still known to the participants.

This handshake takes the place of the usual TLS handshake in other gRPC calls to LND.

The handshake used for each subsequent connection:
IK_secp256k1+CHACHAPOLY1305_SHA256