Protocol-Design
ChaCha20Poly1305@openssh 3 輪 ChaCha 的原因
OpenSSH 使用的 ChaCha20Poly1305 AEAD 結構與 A. Langley 和其他人提出的用於 TLS 的結構略有不同。
- openSSH 版本使用兩個 256 位密鑰。
- 第一個密鑰用於派生 Poly1305 MAC 密鑰並用於加密實際有效負載
- 第二個密鑰用於加密 AAD（openSSH 情況下的 4 字節數據包長度）
- 對於小消息（<=64 字節），此構造導致至少 3 輪 ChaCha20 。
- 用於派生 256 位 Poly1305 密鑰的第一輪 ChaCha20吐出 64 字節，其中最後 32 字節未使用。
- ChaCha20第二輪加密AAD數據（4字節包長）
- 第三輪（及更多）ChaCha20 輪對實際數據包有效負載進行加密。
對於小消息，這似乎會產生高達 33% 的計算時間的不必要成本（如果消息有效負載小於 64 字節）。
問題
- 為什麼不使用 Poly1305 密鑰派生 ChaCha20 輪中未使用的 32 字節來加密數據包長度（或者說 AAD 數據最多 32 字節）？
- 是否需要使用帶有第二個密鑰的第二個 ChaCha20 上下文來加密數據包長度（AAD 數據），或者換句話說，使用第二個密鑰是否更安全（很可能來自同一個密鑰）單個共享密鑰作為第一個密鑰）而不是使用單個密鑰並加密來自派生 Poly1305 密鑰的同一 ChaCha20 輪的 AAD 數據？
擁有兩個 ChaCha 實例的目的是確保一個不能用於攻擊另一個。來自 RFC 草案：
這裡使用了兩個單獨的密碼實例，以便對數據包長度保密，但不會通過在檢查 MAC 之前解密和使用數據包長度來為數據包有效負載密碼創建預言。
在這種情況下，使用與其餘構造相同的密碼實例中第一個塊的未使用部分似乎不允許任何類型的攻擊，因為這始終是密鑰流的同一部分，從未使用過其他任何事情。我想用兩個密碼實例來證明獨立性會更容易，但我懷疑它更多的是關於簡單性和可擴展性。
通過擁有一個單獨的實例，您可以使用普通密碼介面輕鬆地單獨解密數據包長度，而無需添加任何偏移量。通過將加密的數據包長度視為 MAC 的附加數據，您可以使用驗證 MAC 的正常過程，而無需對其進行解密。
如果需要超過 32 字節的附加數據，這種方式也更具可擴展性。從作者的部落格文章看來，似乎有一些計劃來擴展這種對數據包長度的保護。也許這將需要更多額外的數據在主數據包之外以允許更早的處理：
不過我們還沒有完成——攻擊者可能仍然會觀察網路上的加密數據包以嘗試確定它們的長度，而現在它們很可能會成功。我希望在明年的某個時候添加一些功能來挫敗這種流量分析。
即明確回答您的問題，不，我認為使用第二個密碼而不是使用未使用的 32 個字節*更安全。*這樣做似乎還有其他實際原因。