我正在尝试使用 .Net 对称加密 System.Security.Cryptography 来加密许多小文本块，而不会增加太多的存储开销（处理时间并不重要，只是大小）。显而易见的方法是将它们全部塞在一起并将结果加密为一个大块，但这在我的情况下不起作用。
背景是我正在开发一个工具，有人可以使用它向我发送 .docx word 文档，以便我可以在不知道内容的情况下解决结构中的问题。我打算通过对称加密每个<w:t>元素来做到这一点（可以是从单词的一部分到整个段落的任何内容）
我希望能够移动和/或删除此类文本元素，并且用户在我将文档归还时仍然能够解密文档，所以在我看来我别无选择，只能分别加密每个元素，但使用 AES如果你有数千个块，每个块只有几个字节，那么存储开销是巨大的。
对于您不想被阅读的任何信息，最好的加密方式是首先对不存在的信息进行加密。
如果您只关心文档的结构，为什么不将其完全从传输中取出并用占位符替换它呢？
在客户端创建一个数据存储，其中包含与占位符关联的所有已删除内容（例如：{1}、{2}、{3} ... 等）
给自己发送结构和占位符（即那个<w:t>{1}</w:t>）
修复结构。
将固定结构返回给客户端，并在客户端通过将占位符替换为原始内容来将文档一起放回。
这样您就不会传输任何有意义的信息（它保留在客户端，除了文档本身的结构外，没有任何信息会受到损害）。此外，由于大部分内容不存在，因此您将获得更小的文件大小。
更好的是，您可以在将文件发送给您之前让客户查看文件，以便他可以验证所有敏感信息实际上已被删除。
这里没有简单的解决方案，基本上您是在要求我们设计您的整个应用程序。您可以使用 CTR 模式加密，这是分组密码的流模式。使用流模式，您只需要与纯文本字节一样多的加密字节。
也就是说，在流模式下，您仍然需要存储某种随机数。必须存在此 nonce 以保护密文。然而，有时可以根据上下文计算随机数；例如，文件名上的散列应该可以解决问题。不过，这对于文档中的元素可能更难。
请注意，您必须发明一种方案将数据转换为字节并返回（确定字母表，并对字母表进行编码）。如果此方案效率不高，您最终可能会产生巨大的开销。
To encrypt something with the minimal overhead I would suggest a stream cypher, such as Rabbit, or alternatively a block cypher, such as AES in CTR mode. Both avoid the requirement for padding. You will need to think very carefully about what your encryption keys are going to be. There are ways to derive many sub-keys from a single secret master key and some less secure ancillary data. Look up Key Derivation Functions (KDFs). Examples are PBKDF2 and HKDF.
具有 128 位块大小的 AES 平均每个加密片段会产生 8 个字节的开销——在我看来还不错。您可以连接所有片段，将它们加密为一个大块，最后将其拆分并重新放置所有片段。除非您想出一些对策，否则这将一直有效，直到您开始四处移动并删除片段。
例如，您可以使用连接块中的位置为每个加密片段添加前缀，并使用像 RC4 这样的流密码而不是 AES - 这允许您将加密片段恢复到原始顺序，使用任意填充值填充已删除元素的间隙并解密它正确。
这可能会降低开销，但您可能仍需要四个字节。您可能还必须将密文编码为十六进制或 Base64 字符串，因为您不希望 XML 中有原始二进制数据。但是这种编码会比使用 AES 的一些填充产生更大的开销，因此您最好选择最简单的解决方案。
最后的想法 - 当您使用像 AES 这样的分组密码时，在使用相同的密钥加密多个片段时必须小心，因为相同的明文可能会产生相同的密文。有关详细信息，请参阅分组密码操作模式。