对称加密加密许多小块

本文关键字：加密 许多小 对称 | 更新日期: 2023-09-27 17:56:23

我正在尝试使用.Net对称加密System.Security.Cryptography来加密许多小文本块，而不会增加太多的存储开销（处理时间并不重要，只是大小）。显而易见的方法是将它们全部塞在一起并将结果加密为一个大块，但这在我的情况下不起作用。

背景是我正在开发一种工具，有人可以使用它来向我发送.docx Word 文档，以便我可以在不知道内容的情况下解决结构中的问题。我打算通过对称加密每个<w:t>元素（可以是单词的一部分到整个段落的任何内容）来做到这一点

我希望能够移动和/或删除此类文本元素，并且用户在我归还文档时仍然能够解密文档，所以在我看来，我别无选择，只能单独加密每个元素，但是使用 AES，如果您有数千个块，每个块几个字节， 存储开销是巨大的。

对称加密加密许多小块

对于您不想被读取的任何信息，最好的加密是针对一开始就不存在的信息。

如果您只关心文档的结构，为什么不将其完全从传输中取出并替换为占位符？

  • 在客户端创建一个数据存储，其中包含与占位符关联的所有已删除内容（例如：{1}、{2}{3}...等）

  • 向自己发送结构和占位符（即<w:t>{1}</w:t> ）

  • 修复结构。

  • 将固定结构返回到客户端，并在客户端通过将占位符替换为原始内容来将文档放回一起。

这样你就不会传输任何合理的信息（它仍然在客户端，除了文档本身的结构之外，任何信息都不会受到损害）。此外，由于大多数内容不存在，因此传输的文件大小较小。

更好的是，

您可以在将文件发送给您之前让客户查看文件，以便他可以验证所有合理的信息实际上已被删除。

这里没有简单的解决方案，基本上您要求我们设计您的整个应用程序。您可以使用 CTR 模式加密，这是分组密码的流式处理模式。使用流式处理模式，您只需要与纯文本字节一样多的加密字节。

也就是说，使用流媒体模式，您仍然需要存储某种随机数。必须存在此随机数才能保护密文。然而，有时可以从上下文中计算随机数;例如，文件名上的哈希应该可以解决问题。不过，这对于文档中的元素来说可能更难。

请注意，您必须发明一种方案来将数据转换为字节并返回（确定字母表，并对字母表进行编码）。如果此方案效率不高，则最终可能会产生巨大的开销。

块大小为 128 位的 AES 平均导致每个加密片段的开销为 8 字节 - 在我看来还不错。您可以将所有片段连接起来，将它们加密为一个大块，最后将其拆分并再次将所有片段放置到位。这将起作用，直到您开始四处移动并删除片段，除非您想出一些对策。

例如，您可以使用连接块中的位置作为每个加密片段的前缀，并使用像 RC4 这样的流密码而不是 AES - 这允许您将加密片段恢复到其原始顺序，用任意填充值填充已删除元素的空白并正确解密它。

这可能会降低开销，但您可能仍然需要四个字节。您可能还必须将密文编码为十六进制或 Base64 字符串，因为您不希望 XML 中包含原始二进制数据。但是这种编码会产生比使用 AES 的一些填充更大的开销，因此您也可以使用最简单的解决方案。

最后的想法 - 当您使用像AES这样的分组密码时，在使用相同的密钥加密多个片段时必须小心，因为相同的明文可能会产生相等的密码文本。有关详细信息，请参阅分组密码操作模式。

为了以最小的开销加密某些内容，我建议使用流密码器，例如 Rabbit，或者使用块密码，例如 CTR 模式下的 AES。 两者都避免了填充的要求。 您需要非常仔细地考虑您的加密密钥是什么。 有一些方法可以从单个密钥主密钥和一些不太安全的辅助数据中派生许多子密钥。 查找密钥派生函数 （KDF）。 例如PBKDF2和HKDF。

相关文章：