客戶端加密的 nonce 值應該是多少？
我正在使用以下chacha20poly1305 Rust 庫來加密桌面應用程序中的一些數據。使用者提供永遠不會離開他們設備的密鑰來本地加密一些數據，然後將加密的數據發送到伺服器以進行備份。
這個庫需要一個隨機數來加密數據，我不確定這個值應該是什麼。理想情況下，使用者可以僅使用他們的密鑰來恢復這些加密數據。但是，為了解密任何數據，還需要隨機數。在應用程序中硬編碼一些 nonce 感覺很奇怪，但如果我隨機生成一個 nonce，使用者將需要記住這個 nonce 以及他們提供的密鑰，以便恢復加密的數據。
該庫使用
XChaCha20Poly1305並且需要 192 位（24 字節）的隨機數。它是 ChaCha20Poly1305 的擴展，用於增加隨機數大小，ChaCha20 有 96 位隨機數。它沒有標準，只有ietf.org中的一個草案nonce 是“number used once”的首字母縮寫詞。關鍵點是絕對不能再使用 (Key, nonce) 對。我們稱之為隨機數濫用。如果發生這種情況，機密性就會失去，因為攻擊者可以使用嬰兒床拖動技術來揭示兩個明文。甚至有一種自動化的方法來解決它：
- Mason 等人的一種自然語言方法來自動密碼分析兩次密碼
或有關詳細範例，請參閱此問題的答案；
對於 192 位隨機數，隨機隨機數生成是安全的，因為根據生日悖論，您需要加密 $ 2^{96} $ 相同密鑰下的消息以 50% 的機率再次命中相同的隨機數，因此您應該加密更少的消息以確保該機率可以忽略不計。請記住，您需要使用良好的隨機數生成器，例如
/dev/urandom. 如果需要，您仍然可以使用基於計數器的隨機數。我不確定這個值應該是多少。理想情況下，使用者可以僅使用他們的密鑰來恢復這些加密數據。
nonce 不需要保密，可以與文件一起保存而無需加密。這不是不安全，只有密鑰是秘密的。nonce 有助於多次安全地使用密鑰。只要（密鑰，隨機數）對從不出現兩次，它就是安全的。
但是，為了解密任何數據，還需要隨機數。
這是完全正常的，因為解密是使用相同密鑰和隨機數加密的逆過程。
XChaCha20Poly1305生成一個流，我們將它用於 x 或明文。為了重新生成流，我們需要使用相同的輸入。在應用程序中硬編碼一些 nonce 感覺很奇怪，但如果我隨機生成一個 nonce，使用者將需要記住這個 nonce 以及他們提供的密鑰，以便恢復加密的數據。
對 nonce 進行硬編碼是不可接受的，因為它會被多次使用。記住隨機數沒有問題，它是安全的。將其保存在文件中，例如$$ nonce\mathbin|encryptedFile|tag. $$
**注意 1：**是
XChaCha20Poly1305Authenticated Encryption，如果正確使用，它將為您提供機密性、完整性和身份驗證。在解密過程中不能忽略不正確的標籤。如果標籤不匹配，則拋出錯誤。
- 加密
$$ (c,tag)= XChaCha20Poly1305Enc(key,nonce,message) $$
- 解密
$$ (m|\perp) = XChaCha20Poly1305Dec(key,nonce,c) $$
在哪裡 $ \perp $ (
\perp) 如果標籤不匹配則停止。**注2：**最近有一個問題是用相同的密鑰加密大量小文件是否危險？. 也可以使用類似的想法為每個文件生成不同的密鑰。
**最後一點：**如果您使用相同的密鑰和隨機數多次加密和更新數據，這也可能導致隨機數濫用，並且文件的新舊版本的某些部分可能會失去機密性。因此，每次更新都使用一個新的隨機數並再次加密文件。
您應該生成一個隨機* nonce 並將其儲存在密文旁邊，例如添加到它之前。
ChaCha20 和 Poly1305都需要一個唯一的隨機數用於每次加密，否則它們將不安全。但是，nonce 不需要保密，因此您可以將其包含在密文中。
*) 從技術上講，ChaCha20–Poly1305 的 nonce 只需要是唯一的，而不是隨機的，但是使 nonce 隨機且足夠長通常是確保分佈式系統中唯一性的最簡單方法。使用由加密安全的 RNG 生成的隨機 96 位 nonce，將允許您相當安全地加密每個密鑰最多 2 32條消息，同時最多有 2 32的隨機數衝突風險。
如果您不是 100% 信任您的 RNG（考慮到過去存在各種值得注意的作業系統 RNG 錯誤，這可能是一個明智的預防措施），一種可能的“腰帶和吊帶”方法可能是連接 RNG 輸出（至少96 位）具有高解析度時間戳、使用者 ID（如果有）和任何其他您能想到的區別輸入，將它們全部輸入到 SHA-256 之類的加密雜湊函式中，將結果截斷為 96 位，然後用它作為你的隨機數。這樣，只要兩個加密的雜湊輸入不完全匹配，輸出幾乎肯定會不同。
（原則上，您甚至可以將加密密鑰和明文消息作為額外的雜湊輸入包含在隨機數推導中。不過，此時您已經在重新發明SIV的路上了。）