為什麼在閃電網路的傳輸層（BOLT 08）中選擇雜訊 XK 基本模式
我目前正在審查閃電網路協議的傳輸層。它建立在雜訊協議框架握手模式之上。
我不明白：為什麼
XK選擇基本模式？XK <- s ... -> e, es 0 2 <- e, ee 2 1 -> s, se 2 5 <- 2 5首先為什麼不
KK呢？節點是通過 gossip 宣布的，在我的 tcp 套接字上我應該看到誰連接到我能夠查找我的對等方的靜態密鑰。閃電節點可以是私有的，特別是在 tor 上的原因是什麼？其次，為什麼不使用沒有靜態鍵的協議？是我們想要分別為發起者和接收者擁有屬性 2 和 5 的原因嗎？
屬性 2：
發件人身份驗證可防止密鑰洩露模擬 (KCI)。發件人身份驗證基於發件人的靜態密鑰對和收件人的臨時密鑰對之間的臨時靜態 DH（“es”或“se”）。假設相應的私鑰是安全的，則無法偽造此身份驗證。
屬性 5：
**加密到已知收件人，強前向保密。**此有效負載是基於臨時-臨時 DH 以及具有接收者靜態密鑰對的臨時-靜態 DH 進行加密的。假設臨時私鑰是安全的，並且接收者沒有被竊取其靜態私鑰的攻擊者主動冒充，則無法解密此有效負載。
感覺就像我通過引用雜訊協議框架頁面給出了答案。但也許我弄錯了，所以得到你的見解會很棒。
首先為什麼不是KK？節點是通過 gossip 宣布的，在我的 tcp 套接字上我應該看到誰連接到我能夠查找我的對等方的靜態密鑰。
僅根據您收到的 IP 資訊，實際上無法判斷誰在連接您。通過 gossip 協議接收到的公共 IP 資訊僅列出了您可以連接的偵聽端點，但這並不意味著這些端點將是連接到您的端點。事實上，它們不可能，因為偵聽埠需要一個專用套接字，因此來自該 IP 的任何傳出連接都將位於不同的埠上。傳出連接的埠通常是自動分配的，儘管您可以將其顯式綁定到特定的本地埠，但這並不常見。無論如何，您不能綁定到與偵聽套接字相同的埠，並且如果您位於 NAT 後面，則您無法控制接收者可能在其末端看到的埠。
僅 IP 地址是不夠的，因為您可能在網路上的同一 IP 後面有許多節點，或者由於 NAT。您認為哪個節點連接到您以嘗試選擇正確的公鑰將是猜測。
由於無法確定發起者的密鑰，因此雜訊協議中的其他選項是
N,I或X. 我們可以排除，N因為它沒有提供您上面列出的安全保證，並且I會以明文形式洩漏可能被截獲的資訊。X因此是最合理的選擇。對於響應者的公鑰，我們可以再次排除
N，留下K或X。雖然我們已經從 gossip 網路（或 DNS）知道了密鑰，所以傳輸它也沒有什麼意義。此外，接收者隱藏了一些額外的資訊，因為他們的公鑰永遠不會被傳輸。麻省理工學院的 Lit 項目使用該
XX模式。我相信這是因為節點事先沒有關於公鑰的資訊，因為它們使用公鑰的雜湊值來辨識節點。一旦公鑰被傳輸，它們的散列可以與先前已知的公鑰散列進行比較。其次，為什麼不使用沒有靜態鍵的協議？是我們想要分別為發起者和接收者擁有屬性 2 和 5 的原因嗎？
原因正如您在雜訊協議文件中列出的那樣。僅公鑰就足以同時進行加密和身份驗證，而無需依賴任何第三方來提供安全保證。其他協議（如 SSL）具有固有的故障點 - 例如 PKI，它已被濫用於許多現實世界的安全攻擊。（除了它是一個尋租行業。）
在那種情況下，我不明白為什麼使用 HKDF 進行密鑰輪換，而不是使用新的握手來生成新的隨機臨時密鑰。
密鑰輪換的目的是防止在將來密鑰被洩露時解密舊消息。這也可以通過每次新的雜訊交換來完成，但從實際的角度來看，進行握手（多次 ECDH 呼叫）比使用 HKDF 生成新密鑰的計算成本更高。可能還有其他一些我不知道的風險。
我自己嘗試一個答案。實現前向保密以實現長期安全和保護靜態密鑰洩漏和身份驗證以避免欺騙似乎是可取的。實現兩者的唯一模式是使用靜態鍵並且知道或傳輸它們的模式。