In this chapter we will review the Lightning Network's _Encrypted Message
Transport_, sometimes referred to as the _Brontide Protocol_, which allows peers to
In this chapter we will review the Lightning Network's _encrypted message
transport_, sometimes referred to as the _Brontide Protocol_, which allows peers to
establish end-to-end encrypted communication, authentication, and integrity
checking.
[NOTE]
====
Part of this chapter includes some highly technical detail about the encryption protocol and encryption algorithms used in the Lightning Encrypted Transport. You may decide to skip that section, if you are not interested in those details.
Part of this chapter includes some highly technical detail about the encryption protocol and encryption algorithms used in the Lightning encrypted transport. You may decide to skip that section, if you are not interested in those details.
====
=== Encrypted Transport in the Lightning Protocol Suite
The _Encrypted Transport_ component of the Lightning Network and its several components are shown in the left most part of the _Network Connection Layer_ in <<LN_protocol_encrypted_transport_highlight>>:
The _encrypted transport_ component of the Lightning Network and its several components are shown in the left most part of the _Network Connection Layer_ in <<LN_protocol_encrypted_transport_highlight>>.
[[LN_protocol_encrypted_transport_highlight]]
.The Lightning Network Protocol Suite
@ -25,44 +25,42 @@ Unlike the vanilla Bitcoin P2P network, every node in the Lightning Network is
identified by a unique public key which serves as it identity. By default, this
public key is used to end-to-end encrypt _all_ communication within the
network. Encryption by default at the lowest level of the protocol ensures that
all messages are authenticated, are immune to man-in-the-middle attacks,
snooping by 3rd parties, and ensures privacy at the fundamental transport
all messages are authenticated, are immune to man-in-the-middle (MITM) attacks and snooping by third parties, and ensures privacy at the fundamental transport
level. In this chapter, we'll learn about the encryption protocol used by the
Lightning network in detail. Upon completion of this chapter, the reader will
Lightning Network in detail. Upon completion of this chapter, the reader will
be familiar with the state of the art in encrypted messaging protocols, as well
as the various properties such a protocol provides to the network. It's worth
mentioning that the core of the encrypted message transport is _agnostic_ to
its usage within the context of the Lightning Network. As a result, the
custom encrypted message transport Lightning uses, can be dropped into any context
custom encrypted message transport Lightning uses can be dropped into any context
that requires encrypted communication between two parties.
=== The Channel Graph as Decentralized Public Key Infrastructure
As we learned in the chapter on multi-hop forwarding, very node has a long-term
As we learned in the chapter on multihop forwarding, every node has a long-term
identity that is used as the identifier for a vertex during path finding and
also used in the asymmetric cryptographic operations related to the creation of
onion encrypted routing packets. This public key, which serves as a node's
long-term identity is included in the DNS bootstrapping response, as well as
embedded within the Channel Graph. As a result, before a node attempts to
long-term identity, is included in the DNS bootstrapping response, as well as
embedded within the channel graph. As a result, before a node attempts to
connect out to another node on the P2P network, it already knows the public key
of the node it wishes to connect to.
Additionally, if the node being connected to already h a series of public
channels within the graph, then the connecting node is able to further verify
the sanctity of the identity of the node. As the entire channel graph is fully
Additionally, if the node being connected to already has a series of public
channels within the graph, then the connecting node is able to further verify the identity of the node. Because the entire channel graph is fully
authenticated, one can view it as a sort of decentralized public key
infrastructure: in order to register a key, a public channel in the Bitcoin
blockchain must be opened, once a node no longer has any public channels, then
infrastructure (PKI): to register a key, a public channel in the Bitcoin
blockchain must be opened, and once a node no longer has any public channels, then
they've effectively been removed from the PKI.
As Lightning is a decentralized network, it's imperative that no one central
Because Lightning is a decentralized network, it's imperative that no one central
party is designated the power to provision a public key identity within the
network. In place of a central party, the Lightning Network uses the Bitcoin
blockchain as a sybil mitigation mechanism, as gaining an identity on the
blockchain as a Sybil mitigation mechanism because gaining an identity on the
network has a tangible cost: the fee needed to create a channel in the
blockchain, as well as the opportunity cost of the capital allocated to their
channels. In the process of essentially rolling a domain specific PKI, the
Lightning network is able to significantly simply its encrypted transport
Lightning Network is able to significantly simplify its encrypted transport
protocol as it doesn't need to deal with all the complexities that come along
with TLS, the Transport Layer Security protocol.
@ -73,102 +71,100 @@ TLS used in spite of the drawbacks of the existing PKI system? It is indeed a
fact that "self signed certificates" can be used to effectively sidestep the
existing global PKI system by simply asserting to the identity of a given
public key amongst a set of peers. However, even with the existing PKI system
out of the way, TLS has several drawbacks that prompted the creators of the LN
out of the way, TLS has several drawbacks that prompted the creators of the Lightning Network
to instead opt for a more compact custom encryption protocol.
To start with, TLS is a protocol that has been around for several decades and
as a result has evolved over time as new advances have been made in the space
of transport encryption. However, overtime this evolution has caused the
of transport encryption. However, overtime this evolution has caused the
protocol to balloon in size and complexity. Over the past few decades several
vulnerabilities in TLS has been discovered, and patched with each evolution
vulnerabilities in TLS have been discovered and patched, with each evolution
further increasing the complexity of the protocol. As a result of the age of
the protocol several versions and iterations exist, meaning a client needs to
understand many of the prior iterations of the protocol in order to communicate
with a large portion of the public internet further increasing implementation
the protocol, several versions and iterations exist, meaning a client needs to
understand many of the prior iterations of the protocol to communicate
with a large portion of the public internet, further increasing implementation
complexity.
In the past several memory safety vulnerabilities have been discovered in
widely used implementations of SSL/TLS. Packaging such a protocol within every
Lightning node would serve to increase the attack surface of nodes exposed to
to the public peer to peer network. In order to increase the security of the
network as a whole, and minimize exploitable attack surface, the creators of
the LN instead opted to adopt the Noise Protocol Framework. Noise as a protocol
Lightning node would serve to increase the attack surface of nodes exposed to the public peer-to-peer network. To increase the security of the
network as a whole and minimize exploitable attack surface, the creators of
the Lightning Network instead opted to adopt the Noise Protocol Framework. Noise as a protocol
internalizes several of the security and privacy lessons learned over time due
to continual scrutiny of the TLS protocol over decades. In a way, the existence
of Noise allows the community to effective "start over", with a more compact,
of Noise allows the community to effective "start over," with a more compact,
simplified protocol that retains all the added benefits of TLS.
=== The Noise Protocol Framework
The Noise Protocol Framework is a modern, extensible, and flexible message
encryption protocol designed by the creators of the Signal protocol. The Signal
protocol is one of the most widely used message encryption protocols in the
encryption protocol designed by the creators of the Signal Protocol. The Signal Protocol is one of the most widely used message encryption protocols in the
world. It's used by both Signal and Whatsapp, which cumulatively are used by
over a billion people around the world. The Noise framework is the result of
decades of evolution both within academia as well as industry of message
encryption protocols. Lightning uses the Noise protocol framework to implement
a _messageoriented_ encryption protocol used by all nodes to communicate with
encryption protocols. Lightning uses the Noise Protocol Framework to implement
a _message-oriented_ encryption protocol used by all nodes to communicate with
each other.
A communication session using Noise has two distinct phases: the handshake
phase, and the messaging phase. Before two parties can communicate with each
phase and the messaging phase. Before two parties can communicate with each
other, they first need to arrive at a shared secret known only to them which
will be used to encrypt and authenticate messages sent to each other. A flavor
of an authenticated key agreement is used to arrive at a final shared key
between the tow parties. In the context of the Noise protocol, this
authenticated key agreement is referred to as a "handshake". Once that
between the two parties. In the context of the Noise protocol, this
authenticated key agreement is referred to as a _handshake_. Once that
handshake has been completed, both nodes can now being to send each other
encrypted messages. Each time peers need to connect, or reconnect to each
other, a fresh iteration of the handshake protocol is executed ensuring that
forward secrecy (leaking the key of a prior transcript doesn't compromise any
future transcripts) is achieved.
encrypted messages. Each time peers need to connect or reconnect to each
other, a fresh iteration of the handshake protocol is executed, ensuring that
forward secrecy is achieved (leaking the key of a prior transcript doesn't compromise any
future transcripts).
As the Noise protocol allows a protocol designer to drop choose from several
Because the Noise Protocol allows a protocol designer to choose from several
cryptographic primitives such as symmetric encryption and public key
cryptography, its customary that each flavor of the Noise protocol is referred
to by a unique name. In the spirit of "Noise", each flavor of the protocol
selects a name derived from some sort of "noise". In the context of the
cryptography, it's customary that each flavor of the Noise Protocol is referred
to by a unique name. In the spirit of "Noise," each flavor of the protocol
selects a name derived from some sort of "noise." In the context of the
Lightning Network, the flavor of the Noise protocol used is sometimes referred to
as "Brontide". A brontide is a low billowing noise, similar to what one would
as Brontide. A _brontide_ is a low billowing noise, similar to what one would
hear during a thunderstorm when very far away.
=== Lightning Encrypted Transport in Detail
In this section we will break down the Lightning Encrypted Transport protocol and delve into the details of the cryptographic algorithms and protocol used to establish encrypted, authenticated and integrity-assured communications between peers. Feel free to skip this section if you find this level of detail daunting.
In this section we will break down the Lightning encrypted transport protocol and delve into the details of the cryptographic algorithms and protocol used to establish encrypted, authenticated, and integrity-assured communications between peers. Feel free to skip this section if you find this level of detail daunting.
After the initial handshake initialization, we can begin the actual execution
of the handshake process. The handshake is compromised of a series of
three messages sent between the initiator and responder, hence referred to as
"acts". As each act is a single message sent between the parties, a handshake
of the handshake process. The handshake is composed of a series of
three messages sent between the initiator and responder, henceforth referred to as
"acts." Because each act is a single message sent between the parties, a handshake
is completed in a total of 1.5 round trips (0.5 for each act).
The first act completes the initial portion of the incremental Triple Diffie
Hellman key exchange (using a new ephemeral key generated by the initiator),
The first act completes the initial portion of the incremental triple Diffie–Hellman (DH) key exchange (using a new ephemeral key generated by the initiator)
and also ensures that the initiator actually knows the long-term public key of
the responder. During the second act, the responder transmits the thermal key
they wish to use for the session to the initiator, and one again incrementally
mixes this new key into the Triple DH handshake. During the third and final
the responder. During the second act, the responder transmits the ephemeral key
they wish to use for the session to the initiator, and once again incrementally
mixes this new key into the triple DH handshake. During the third and final
act, the initiator transmits their long-term static public key to the
responder, and executes the final DH operation to mix that into the final
responder and executes the final DH operation to mix that into the final
resulting shared secret.
====== Act One
@ -346,7 +344,7 @@ The handshake message is _exactly_ 50 bytes: 1 byte for the handshake
version, 33 bytes for the compressed ephemeral public key of the initiator,
The prefixed message length is encoded as a 2-byte big-endian integer, for a
total maximum packet length of `2 + 16 + 65535 + 16` = `65569` bytes.
total maximum packet length of `2 + 16 + 65,535 + 16` = `65,569` bytes.
====== Encrypting and Sending Messages
====== Encrypting and sending messages
In order to encrypt and send a Lightning message (`m`) to the network stream,
To encrypt and send a Lightning message (`m`) to the network stream,
given a sending key (`sk`) and a nonce (`sn`), the following steps are
completed:
@ -562,42 +560,42 @@ completed:
3. Encrypt `l` (using `ChaChaPoly-1305`, `sn`, and `sk`), to obtain `lc`
(18 bytes)
* The nonce `sn` is encoded as a 96-bit little-endian number. As the
decoded nonce is 64 bits, the 96-bit nonce is encoded as: 32 bits
of leading 0s followed by a 64-bit value.
* The nonce `sn` MUST be incremented after this step.
decoded nonce is 64 bits, the 96-bit nonce is encoded as 32 bits
of leading zeros followed by a 64-bit value.
* The nonce `sn` must be incremented after this step.
* A zero-length byte slice is to be passed as the AD (associated data).
4. Finally, encrypt the message itself (`m`) using the same procedure used to
encrypt the length prefix. Let encrypted ciphertext be known as `c`.
* The nonce `sn` MUST be incremented after this step.
encrypt the length prefix. Let this encrypted ciphertext be known as `c`.
* The nonce `sn` must be incremented after this step.
5. Send `lc || c` over the network buffer.
====== Receiving and Decrypting Messages
====== Receiving and decrypting messages
In order to decrypt the _next_ message in the network stream, the following
To decrypt the _next_ message in the network stream, the following
steps are completed:
1. Read _exactly_ 18 bytes from the network buffer.
2. Let the encrypted length prefix be known as `lc`.
3. Decrypt `lc` (using `ChaCha20-Poly1305`, `rn`, and `rk`), to obtain the size of
3. Decrypt `lc` (using `ChaCha20-Poly1305`, `rn`, and `rk`) to obtain the size of
the encrypted packet `l`.
* A zero-length byte slice is to be passed as the AD (associated data).
* The nonce `rn` MUST be incremented after this step.
4. Read _exactly_ `l+16` bytes from the network buffer, and let the bytes be
* The nonce `rn` must be incremented after this step.
4. Read _exactly_ `l+16` bytes from the network buffer, and let the bytes be
known as `c`.
5. Decrypt `c` (using `ChaCha20-Poly1305`, `rn`, and `rk`), to obtain decrypted
plaintext packet `p`.
* The nonce `rn` MUST be incremented after this step.
5. Decrypt `c` (using `ChaCha20-Poly1305`, `rn`, and `rk`) to obtain decrypted
plain-text packet `p`.
* The nonce `rn` must be incremented after this step.
===== Lightning message key rotation
Changing keys regularly and forgetting previous keys is useful to prevent the
decryption of old messages, in the case of later key leakage (i.e. backwards
decryption of old messages, in the case of later key leakage (i.e., backward
secrecy).
Key rotation is performed for _each_ key (`sk` and `rk`) _individually_. A key
is to be rotated after a party encrypts or decrypts 1000 times with it (i.e.
is to be rotated after a party encrypts or decrypts 1,000 times with it (i.e.,
every 500 messages). This can be properly accounted for by rotating the key
once the nonce dedicated to it exceeds 1000.
once the nonce dedicated to it exceeds 1,000.
Key rotation for a key `k` is performed according to the following steps:
@ -609,8 +607,8 @@ Key rotation for a key `k` is performed according to the following steps:
=== Conclusion
Lightning's underlying transport encryption is based on the Noise protocol and offers strong security guarantees of privacy, authenticity and integrity for all communications between Lightning peers.
Lightning's underlying transport encryption is based on the Noise Protocol and offers strong security guarantees of privacy, authenticity, and integrity for all communications between Lightning peers.
Unlike Bitcoin where peers often communicate "in the clear" (without encryption), all Lightning communications are encrypted peer-to-peer. In addition to transport encryption (peer-to-peer), in the Lightning Network payments are *also* encrypted into onion packets (hop-to-hop) and payment details are sent out-of-band between the sender and recipient (end-to-end). The combination of all these security mechanisms is cumulative and provides layered defense against de-anonymization, man-in-the-middle attacks and network surveillance.
Unlike Bitcoin where peers often communicate "in the clear" (without encryption), all Lightning communications are encrypted peer-to-peer. In addition to transport encryption (peer-to-peer), in the LN payments are _also_ encrypted into onion packets (hop-to-hop) and payment details are sent out-of-band between the sender and recipient (end-to-end). The combination of all these security mechanisms is cumulative and provides layered defense against deanonymization, man-in-the-middle attacks, and network surveillance.
Of course, no security is perfect and we will see in <<security_and_privacy>> that these properties can be degraded and attacked. However, the Lightning Network significantly improves upon the privacy of Bitcoin.