<blockquote>
  <p>First of all why not KK? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer. </p>
</blockquote>

<p>It isn't really possible to tell who is connecting to you based solely on the IP information you receive. The public IP information received over the gossip protocol only lists the <em>listening</em> endpoints which you can connect to, but this does not imply that those endpoints will be the ones connecting to you. In fact, they can't be, because the listening port requires a dedicated socket, so any outgoing connections from that IP would be on a different port. The port for outgoing connections is usually assigned automatically, although you can bind it to a specific local port explicitly, this is not common. You can't bind to the same port as the listening socket anyway, and if you're behind a NAT you have no control over the port the recipient might see at their end.</p>

<p>The IP address alone is not sufficient because you could have many nodes behind the same IP on a network, or due to NAT. It would be guesswork which node you think is connecting to you to try and pick the right public key.</p>

<p>Since the initiator's key can't be known for sure, the other options from the Noise protocol are <code>N</code>, <code>I</code> or <code>X</code>. We can rule out <code>N</code> because it does not provide the security guarantees you listed above, and <code>I</code> leaks information in plaintext which could be intercepted. <code>X</code> is therefore the most reasonable option.</p>

<p>For the responder's public key, we can again rule out <code>N</code>, leaving either <code>K</code> or <code>X</code>. We already know the key though, from the gossip network (or DNS), so there is little point on transmitting it also. Additionally, the recipient has a little extra information hiding because their public key is never transmitted.</p>

<p>The Lit project from MIT uses the <code>XX</code> pattern. I believe this is because nodes don't have information about public keys in advance because they use hashes of the public keys to identify nodes instead. Once the public keys have been transmitted, their hashes can be compared to the previously known public key hashes.</p>

<blockquote>
  <p>Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively? </p>
</blockquote>

<p>The reasons are as you've listed from the Noise protocol document. The public keys alone are sufficient to have both encryption and authentication without relying on any third party for the security guarantees. Other protocols such as SSL have inherent points of failure - such as the PKI, which has been abused for many real world attacks on security. (In addition to it being a rent-seeking industry.)</p>

<blockquote>
  <p>In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys. </p>
</blockquote>

<p>The purpose of the key rotation is to prevent the decryption of older messages if the keys are compromised in the future. This could also be done with a new Noise exchange each time, but from a practical point of view it is more computationally expensive to do a handshake (multiple ECDH calls) than to produce new keys with the HKDF. There may be some other risks to it that I'm not aware of though.</p>

CC BY-SA 4.0
2019-03-13T15:44:24.163Z
For the first part of the answer I believe I can choose port 9735 as an outgoing port even though I am listening on 9735 for incoming connections. The tcp header has two port fields. The src port and the dest port. As soon as the tcp handshake took place the pair 9735/9735 Rieger with the ip addresses an seq and ACK numbers are my end to end connection.
Rene Pickhardt
CC BY-SA 4.0
2019-03-13T15:55:45.057Z
The outgoing address you connect to is not the same as the local port you're using for the socket. You connect to port 9735 because this is the listening port used by the person you're connecting to. The port used on your end is automatically chosen, and if the recipient looks at who is connecting, they'll see your public facing IP and this seemingly random port. They can't uniquely identify you based on this information.
Mark H
CC BY-SA 4.0
2019-03-13T14:37:07.177Z
2019-03-13T15:12:52.973Z
2019-03-13T15:12:52.973Z
Mark H
<p>I try an answer myself. It seems desireable to achieve <a href="https://en.m.wikipedia.org/wiki/Forward_secrecy" rel="nofollow noreferrer">forward secrecy</a> for longterm security and protection of static key leakage and authentication to avoid spoofing. The only patterns which achieve both are the ones that use static keys and either knowing or transferring them. </p>

CC BY-SA 4.0
2019-03-13T11:25:22.570Z
In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys.
Rene Pickhardt
CC BY-SA 4.0
2019-03-13T11:19:07.927Z
2019-03-13T11:19:07.927Z
Rene Pickhardt
<p>I am currently reviewing the transport layer of the Lightning network protocol. It builds on top of the <a href="http://noiseprotocol.org/noise.html#handshake-patterns" rel="nofollow noreferrer">noise protocol framework handshake patterns</a>. </p>

<p>What I don't get: Why was the fundamental pattern <code>XK</code> chosen?</p>

<pre><code>XK
  &lt;- s
  ...
  -&gt; e, es                  0                2
  &lt;- e, ee                  2                1
  -&gt; s, se                  2                5
  &lt;-                        2                5
</code></pre>

<p>First of all why not <code>KK</code>? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer. Was the reason so that lightning nodes could be private and in particular on tor? </p>

<p>Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively? </p>

<p>Property 2:</p>

<blockquote>
  <p><strong>Sender authentication resistant to key-compromise impersonation (KCI)</strong> . The sender authentication is based on an ephemeral-static DH ("es" or "se") between the sender's static key pair and the recipient's ephemeral key pair. Assuming the corresponding private keys are secure, this authentication cannot be forged.</p>
</blockquote>

<p>Property 5:</p>

<blockquote>
  <p><strong>Encryption to a known recipient, strong forward secrecy.</strong> This payload is encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static DH with the recipient's static key pair. Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated by an attacker that has stolen its static private key, this payload cannot be decrypted.</p>
</blockquote>

<p>It feels like I have given the answer by quoting from the noise protocol framework page. But maybe I am mistaking so it would be great to get your insights. </p>

<security><lightning-network><protocol><encryption>
Why was noise XK fundamental pattern chosen in the transport layer (BOLT 08) of the lightning network
Rene Pickhardt
# Why was noise XK fundamental pattern chosen in the transport layer (BOLT 08) of the lightning network

(Asked by: username_0 on 2019-03-13)

I am currently reviewing the transport layer of the Lightning network protocol. It builds on top of the [noise protocol framework handshake patterns](http://noiseprotocol.org/noise.html#handshake-patterns).

What I don't get: Why was the fundamental pattern `XK` chosen?

```
XK
  <- s
  ...
  -> e, es                  0                2
  <- e, ee                  2                1
  -> s, se                  2                5
  <-                        2                5

```

First of all why not `KK`? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer. Was the reason so that lightning nodes could be private and in particular on tor?

Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively?

Property 2:

> **Sender authentication resistant to key-compromise impersonation (KCI)** . The sender authentication is based on an ephemeral-static DH ("es" or "se") between the sender's static key pair and the recipient's ephemeral key pair. Assuming the corresponding private keys are secure, this authentication cannot be forged.

Property 5:

> **Encryption to a known recipient, strong forward secrecy.** This payload is encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static DH with the recipient's static key pair. Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated by an attacker that has stolen its static private key, this payload cannot be decrypted.

It feels like I have given the answer by quoting from the noise protocol framework page. But maybe I am mistaking so it would be great to get your insights.

**Tags:** security, lightning-network, protocol, encryption


---

## 2 answers

### Answer by username_1 on 2019-03-13. Score: 1

> First of all why not KK? Nodes are announced via gossip and on my tcp socket I should see who connected to me being able to look up the static key of my peer.

It isn't really possible to tell who is connecting to you based solely on the IP information you receive. The public IP information received over the gossip protocol only lists the *listening* endpoints which you can connect to, but this does not imply that those endpoints will be the ones connecting to you. In fact, they can't be, because the listening port requires a dedicated socket, so any outgoing connections from that IP would be on a different port. The port for outgoing connections is usually assigned automatically, although you can bind it to a specific local port explicitly, this is not common. You can't bind to the same port as the listening socket anyway, and if you're behind a NAT you have no control over the port the recipient might see at their end.

The IP address alone is not sufficient because you could have many nodes behind the same IP on a network, or due to NAT. It would be guesswork which node you think is connecting to you to try and pick the right public key.

Since the initiator's key can't be known for sure, the other options from the Noise protocol are `N`, `I` or `X`. We can rule out `N` because it does not provide the security guarantees you listed above, and `I` leaks information in plaintext which could be intercepted. `X` is therefore the most reasonable option.

For the responder's public key, we can again rule out `N`, leaving either `K` or `X`. We already know the key though, from the gossip network (or DNS), so there is little point on transmitting it also. Additionally, the recipient has a little extra information hiding because their public key is never transmitted.

The Lit project from MIT uses the `XX` pattern. I believe this is because nodes don't have information about public keys in advance because they use hashes of the public keys to identify nodes instead. Once the public keys have been transmitted, their hashes can be compared to the previously known public key hashes.

> Second of all why not using protocols without static keys? Is the reason that we wanted to have property 2 and 5 for initiator and recipient respectively?

The reasons are as you've listed from the Noise protocol document. The public keys alone are sufficient to have both encryption and authentication without relying on any third party for the security guarantees. Other protocols such as SSL have inherent points of failure - such as the PKI, which has been abused for many real world attacks on security. (In addition to it being a rent-seeking industry.)

> In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys.

The purpose of the key rotation is to prevent the decryption of older messages if the keys are compromised in the future. This could also be done with a new Noise exchange each time, but from a practical point of view it is more computationally expensive to do a handshake (multiple ECDH calls) than to produce new keys with the HKDF. There may be some other risks to it that I'm not aware of though.

> **Comments:**
> **username_0**: For the first part of the answer I believe I can choose port 9735 as an outgoing port even though I am listening on 9735 for incoming connections. The tcp header has two port fields. The src port and the dest port. As soon as the tcp handshake took place the pair 9735/9735 Rieger with the ip addresses an seq and ACK numbers are my end to end connection.  
> **username_1**: The outgoing address you connect to is not the same as the local port you're using for the socket. You connect to port 9735 because this is the listening port used by the person you're connecting to. The port used on your end is automatically chosen, and if the recipient looks at who is connecting, they'll see your public facing IP and this seemingly random port. They can't uniquely identify you based on this information.  

---

### Answer by username_0 on 2019-03-13. Score: 0

I try an answer myself. It seems desireable to achieve [forward secrecy](https://en.m.wikipedia.org/wiki/Forward_secrecy) for longterm security and protection of static key leakage and authentication to avoid spoofing. The only patterns which achieve both are the ones that use static keys and either knowing or transferring them.

> **Comments:**
> **username_0**: In that case I don't understand why key rotation takes place with HKDF and not a new handshake generating new random ephemeral keys.  

---

