在加密之前，没有额外的明文手动填充，`box`的` the‘结构安全吗？

Question

我阅读了下列问题和答案：

• 利比钠密码箱有多安全？
• 从利布纳密码的密文中可以学到什么_盒_脱离()？

然而，这两篇文章都没有讨论在阅读填充API上的填充文档时引起我注意的一个重要细节：

大多数现代密码结构都披露消息长度。给定消息的密文将始终具有相同的长度，或向其添加一定数量的字节。对于大多数应用程序来说，这不是一个问题。但在某些特定情况下，例如交互式远程shell，隐藏长度可能是可取的。

据我所知，这也适用于框，因为它们使用的是一个流密码，XSalsa20，在引擎盖下。然而，盒式API的文档声称：

_easy和_detached API通过不需要填充、复制或复杂的指针算法来提高可用性，而且速度更快。

我还在许多地方读到，由于几个原因(例如确定性引起的延展性)，未加填充的对称密钥加密是不安全的。但是，在Box实现中，非对称密钥不是用于加密明文本身，而是用于导出XSalsa20对称密码的共享密钥。

总的来说，这让我怀疑填充的问题是否仍然相关，是否应该在将消息传递给crypto_box_easy之前手动填充它们(很明显，当它们从crypto_box_easy_open返回时，应该卸载它们)以获得更好的安全性？我不能完全连接这些点，我也不想让我正在编写的密码变得毫无用处(因为这本身就会增加安全攻击的表面)。

Answer 1

_easy和_detached API通过不需要填充、复制或复杂的指针算法来提高可用性，而且速度更快。

这指的是最初的NaCl API的工作方式。您必须在消息之前添加一些零，并在解密后删除它们。但这正是函数必须使用的方式。它使原始实现更容易，但使用起来更复杂。它没有在消息中添加任何实际填充。

(例如由决定论引起的延展性)

这里不相干。现在确保相同的消息加密两次产生不同的密文。

只有当您考虑到攻击者可能从消息的长度中学到相关内容时，才应该添加填充。如果您发送加密密码，这将显示密码的长度，这可能是不可取的。如果唯一可以交换的消息是“是”和“否”，攻击者将不需要解密任何东西来猜测消息。在这里，填充物是有用的。

但对于大多数应用程序来说，它是无用的。