我正在编写适用于“流”的 XXTEA 加密算法的实现，即可以像这样使用：crypt mykey < myfile > 输出。
必要条件之一是它根本无法访问文件（它只读取固定大小的块，直到找到 EOF）。该算法需要数据字节是 4 的倍数，因此需要添加一个填充。
对于纯文本，一个好的解决方案是填充 NULL，在解密时忽略 NULL，但相同的策略不能用于二进制流（可以包含嵌入的 NULL）。
我已经阅读了常见的解决方案，比如用丢失的字符数填充（如果它错过了 3 个字符，然后在末尾附加一个 3、3、3）等等，但我想知道：有更优雅的解决方案吗？
阅读：http: //msdn.microsoft.com/en-us/library/system.security.cryptography.paddingmode.aspx
它有一个常用填充方法的列表，例如：
PKCS7 - PKCS #7 填充字符串由一个字节序列组成，每个字节等于添加的填充字节的总数。
ANSIX923 填充字符串由长度前用零填充的字节序列组成。
ISO10126 填充字符串由长度之前的随机数据组成。
例子：
原始数据：01 01 01 01 01
PKCS #7：01 01 01 01 01 03 03 03
ANSIX923 01 01 01 01 01 00 00 03
ISO10126：01 01 01 01 01 CD A9 03
阅读这个问题，这似乎是安全方面的问题。简单地说，你有一个 api，它需要 4 个字节的倍数作为输入，而你并不总是这样。
如果您不能保证二进制流不关心，那么将最多 3 个字节附加到任何二进制流上都是危险的。将 0 附加到 exe 文件的末尾并不重要，因为 exe 文件具有指定所有剩余位的相关大小的标头。将 0 附加到 pcx 文件的末尾会破坏它，因为 pcx 文件的标头从文件末尾开始特定数量的字节。
所以你真的别无选择 - 你没有选择可以使用的魔法填充字节，这些字节保证永远不会在二进制流的末尾自然发生：你必须始终附加至少一个额外的双字信息来描述所使用的填充字节。
实际上，我希望一个好的流密码根本不需要填充。例如，RC4 不需要填充，是一种非常强大的流密码。但是，如果攻击者可以将不同选择的数据提供给加密例程，该例程始终使用相同的密钥，并且还可以访问加密数据，则它可能会受到攻击。选择正确的输入数据并分析输出数据可用于恢复加密密钥，无需暴力攻击；但除此之外，RC4 非常安全。
如果需要填充，恕我直言，它不是流密码。好像你填充为 4 字节的倍数或 16 字节的倍数，有什么巨大的区别？如果它被填充为 16 字节的倍数，您几乎可以使用任何分组密码。实际上你的密码是一个分组密码，它只适用于 4 字节块。它是系统上的流密码，其中每个“符号”都是 4 字节（例如，当加密 UTF-32 文本时，在这种情况下，数据肯定总是 4 的倍数，因此永远不会有任何填充）。