libsodium 的“盒子”結構是否安全，無需在加密前額外手動填充明文？
我已閱讀以下問題和答案：
但是，這些都沒有討論在閱讀有關填充 API 的 libsodium 文件時引起我注意的重要細節：
大多數現代密碼結構都公開了消息長度。給定消息的密文將始終具有相同的長度，或者向其添加恆定數量的字節。對於大多數應用程序，這不是問題。但在某些特定情況下，例如互動式遠端 shell，隱藏長度可能是可取的。
據我所知，這也適用於盒子，因為它們在底層使用流密碼 XSalsa20。但是，Box API 的文件聲稱：
_easy和_detachedAPI 更快，並且通過不需要*填充、*複製或棘手的指針運算來提高可用性。我還在各個地方讀到未填充的對稱密鑰密碼術由於多種原因（例如由確定性引起的延展性）不安全。然而，在 Box 實現中，非對稱密鑰不用於加密明文本身，而是用於導出 XSalsa20 對稱密碼的共享密鑰。
總的來說，這讓我想知道填充問題是否仍然相關，以及我是否應該在將它們傳遞給之前手動填充我的消息
crypto_box_easy（顯然，當它們從返回時取消填充crypto_box_easy_open）以獲得更好的安全性？我不能把這些點聯繫起來，我也不想讓我正在編寫的加密程式碼變得無用地複雜化（因為它本身可能會增加安全攻擊面）。
_easy 和 _detached API 更快，並且通過不需要填充、複製或棘手的指針運算來提高可用性。
這是指原始 NaCl API 的工作方式。您必須在消息前添加一些零，並在解密後將其刪除。但這正是必須使用這些功能的方式。它使原始實現更容易，但使用起來更棘手。它沒有為消息添加任何實際填充。
（例如由確定性引起的延展性）
這裡無關緊要。隨機數確保相同的消息加密兩次產生不同的密文。
僅當您認為攻擊者可能從消息的長度中了解相關內容時，才應添加填充。如果您要發送加密密碼，這將顯示密碼的長度，這可能是不可取的。如果可以交換的唯一消息是“是”和“否”，則攻擊者將不需要解密任何內容來猜測消息。在這裡，填充將很有用。
但對於大多數應用程序來說，它是無用的。