Protocol-Design
是否可以使用 XSalsa20-Poly1305 發送加密密鑰，並使用 ChaCha20-Poly1305 發送後續消息？
我正在一個有點不尋常的環境中研究加密協議：通信方可以通過安全通道共享任意長的密鑰。
如果不需要前向保密，似乎可以簡單地使用 256 位共享密鑰加密/驗證（隨機）256 位密鑰，然後開始發送使用 ChaCha20-Poly1305（或 AES-GCM）加密的消息。假設底層密碼是安全的，這似乎是微不足道的（證明：攻擊者無法在不破壞 AEAD 或知道其密鑰的情況下偽造或重新排序第一個消息 - 但要獲得密鑰，攻擊者需要破解 XSalsa20-Poly1305或者使用的 CSPRNG，或者需要重用 XSalsa20-Poly1305 的 192 位隨機數，或者需要洩露共享秘密。AEAD 和 XSalsa20-Poly1305 都被廣泛認為是安全的，共享秘密必須假定為秘密，並且 192 位隨機數衝突的機率可以忽略不計）。每次計數器從 0 開始，
TLS-PSK 就是為此而設計的，但它非常複雜。這似乎要簡單得多。
是的，這是安全的。
更簡單的是直接使用 XSalsa20-Poly1305 和長期密鑰。您可以使用 Poly1305 以及基於 ChaCha 的組合驗證任何其他數據。但是，如果您使案例如 libsodium，其中前一個介面不支持附加數據，而後者有一個短隨機數，那麼按照您的建議組合它們也是可以的。
請注意，關於您的評論：無需單獨驗證消息長度。預設情況下，整個消息已經過身份驗證，因此您只需計算其長度即可。
如果您需要驗證的唯一附加數據是序列號，則可以將其作為 192 位隨機數的一部分包含在內，並且僅使用 XSalsa20-Poly1305。128 位隨機部分和 64 位序列號就可以了，160/32 會更好。