隱藏隨機數可以獲得多少安全性？
當可以將公共隨機數視為元數據時，它們可能會對隱私造成問題。如果您執行諸如使用消息的散列作為隨機數之類的操作，它們也可能會給安全帶來麻煩。
PASETO現在使用 HKDF 在具有 256 位鹽的輸入密鑰材料上導出隨機數和密鑰。因此，傳遞給 AES-CTR 和 XChaCha 的實際隨機數並未公開披露。
AES-256-CTR 和 XChaCha20 使用的 nonce 將來自 HKDF 輸出（現在 v3.local 為 48 字節，v4.local 為 56 字節）。每個 HKDF 輸出的前 32 個字節將用作密鑰。剩餘的字節將用作底層密碼的隨機數。
TripleSec是 Keybase的一個過度殺傷的多重加密庫，用於加密內部隨機數。
TripleSec 技術採取了 Schneier 沒有建議的進一步步驟，即用外部加密算法保護內部 IV，並且隻公開最外面的 IV。儘管我們無法證明這會使方案更安全，但這似乎是一個合理的想法：如果我們不必透露密碼輸入，為什麼還要透露？
由於隨機數和攻擊者的密鑰一樣是秘密的，從這些類型的方法中可能獲得多少安全性？對於小的隨機數（例如 64 位和 96 位），它是否仍然有意義？
由於子密鑰派生，我認為這對 XChaCha20 來說非常好。
隱藏 nonce 並沒有帶來切實的好處。在輸入塊是常量、密鑰、隨機數和計數器的串聯的 ChaCha 的情況下，使用隨機和秘密隨機數可以被認為是擴展密鑰並減小隨機數的大小。對於具有 256 位密鑰、96 位隨機數和 32 位計數器的 IETF ChaCha，您可以有效地將其轉換為具有 352 位密鑰和 32 位計數器的密碼。當然，這確實增加了從技術上提高安全性的密鑰空間，但沒有必要這樣做，因為 256 位就足夠了。它與分組密碼的工作方式略有不同。
有趣的是，Linux 核心的隨機驅動程序使用秘密隨機數（和秘密計數器）將 ChaCha20 初始化為其 CSPRNG。它使用隨機的 64 位計數器和隨機數，因此密鑰實際上是 320 位（儘管核心只重新設定 256 位密鑰的種子）*。*這樣做並不是為了提高安全性，而是因為使用常量和隨機數據初始化整個 ChaCha 輸入塊更容易。
不過，我必須回應其他人所說的話，並警告您，竭盡全力隱藏 nonce 可能是個壞主意！如果您的設計使得隨機數自然是秘密的，那麼就沒有理由將其公開，但也沒有理由嘗試設計一個必須保密的系統。
我的建議：如果公開nonce需要更多的工作，那就保密吧。如果將其保密需要**更多工作，則將其公開。**沒有必要把事情複雜化。