為什麼 NaCl 庫中的 crypto_box 功能會將 nonce 暴露給程序員？
NaCl 庫中 crypto_box API的想法是讓程序員遠離技術細節，並提供易於使用的函式來加密和加密消息。
鑑於我剛剛寫的內容，我不明白為什麼在這個 API 中暴露了*nonce的想法。*解釋什麼是 nonce 以及如何使用它佔據了文件的很大一部分，而且很可能會出錯。在幕後生成一個隨機字節串不是更好嗎？
作者關於 NaCl的文章觸及了這個主題。我將在這裡引用相關的部分：
隨機數。crypto_box API 將 nonce 生成留給呼叫者。這並不意味著隨機數生成不是密碼學家工作的一部分。相反，我們認為密碼學家不僅應該對 nonce 負責，還應該對高級網路協議的其他安全方面負責。nonce 的暴露只是反映了 nonce 以不同方式集成到高級協議中的事實。
總是生成一個隨機的 24 字節 nonce n，並將這個 nonce 作為已驗證密文的一部分進行傳輸，這似乎是最簡單的；24 字節的隨機字元串發生衝突的可能性可以忽略不計。如果密文很長，那麼人們可以容忍生成這種隨機性和將每個密文擴展 24 個字節的成本。然而，隨機隨機數無法阻止最簡單的偽造類型，即重放。防止重放的一種標準策略是在每個數據包中包含一個遞增的數字，並拒絕任何數量不大於最後一個已驗證數據包中的數字的數據包；使用這些序列號作為隨機數比給每個數據包一個數字和一個隨機隨機數更簡單。另一方面，選擇公共隨機數作為序列號意味著洩露流量資訊，否則攻擊者收集這些資訊的成本會更高。文獻中出現了幾種不同的解決方案；對隨機數生成的限制通常與使用者期望的安全和隱私問題直接相關。
NaCl 的目前應用程序，例如 DNSCurve 和 CurveCP，對 nonce、重放、前向保密和許多其他比 crypto_box API 更高級別的安全問題有不同的要求。nonceless API 在所有這些應用程序中都需要更高級別的複雜性，並且不會簡化它們的安全分析。