填充 - 加密算法答案

【问题标题】：Padding - Encryption algorithm填充 - 加密算法
【发布时间】：2010-09-15 05:20:11
【问题描述】：

我正在编写一个适用于“流”的 XXTEA 加密算法的实现，即可以像这样使用：crypt mykey output。

其中一个必要条件是它根本无法访问文件（它只读取固定大小的块，直到找到 EOF）。该算法需要数据字节是4的倍数，所以需要添加一个填充。

对于纯文本，一个好的解决方案是用 NULL 填充，在解密时忽略 NULL，但相同的策略不能用于二进制流（可以包含嵌入的 NULL）。

我已经阅读了常见的解决方案，比如用丢失的字符数填充（如果它错过了 3 个字符，则在末尾附加一个 3、3、3）等等，但我想知道：有一个更优雅的解决方案?

【问题讨论】：

您是否有理由自己实现它而不是使用预先存在的实现？很容易意外创建不安全的密码系统。
主要是为了学习。我已经改变了范围，现在我让它在“文件”上工作，它允许我获取总大小并编写一个标题，通知添加的填充量。感谢所有 cmets 和建议。

标签： c cryptography stream padding

【解决方案1】：

阅读这个问题，它的安全方面似乎没有实际意义。简而言之，您有一个 api 需要 4 个字节的倍数作为输入，而您并不总是这样。

如果您不能保证二进制流不关心，那么将最多 3 个字节附加到任何二进制流上是危险的。将 0 附加到 exe 文件的末尾并不重要，因为 exe 文件具有指定所有剩余位的相关大小的标头。将 0 附加到 pcx 文件的末尾会破坏它，因为 pcx 文件的标头从文件末尾开始特定数量的字节。

所以你真的别无选择 - 你没有选择可以使用的魔法填充字节，这些字节保证永远不会在二进制流的末尾自然发生：你必须总是附加至少一个描述使用的填充字节的附加双字信息。

【讨论】：

【解决方案2】：

实际上，我希望一个好的流密码根本不需要填充。例如，RC4 不需要填充，是一种非常强大的流密码。但是，如果攻击者可以将不同的选择数据提供给加密例程，该例程始终使用相同的密钥，并且还可以访问加密的数据，则它可能会受到攻击。选择正确的输入数据并分析输出数据可用于恢复加密密钥，无需暴力攻击；但除此之外，RC4 非常安全。

如果需要填充，恕我直言，它不是流密码。好像你填充为 4 字节的倍数或 16 字节的倍数，有什么巨大的区别？如果它被填充为 16 字节的倍数，您几乎可以使用任何分组密码。实际上你的密码是一个分组密码，它只适用于 4 字节块。它是系统上的流密码，每个“符号”都是 4 字节（例如，当加密 UTF-32 文本时，在这种情况下，数据肯定总是 4 的倍数，因此永远不会有任何填充）。

【讨论】：

TEA 是一种分组密码，他只是想将它与流程序一起使用。填充是标准解决方案，可以使用可以删除的魔法值，也可以使用提供数据长度的标头。

【解决方案3】：

阅读ciphertext stealing。可以说它比纯文本填充要优雅得多。另外，我建议使用大于 4 字节的块大小——64 位可能是最低限度。

严格来说，DIY 密码学是一个危险的想法；很难击败整个加密社区尝试过但未能破解的算法。玩得开心，并考虑阅读this，或至少从 Schneier 的“相关阅读”部分阅读。

【讨论】：

他正在使用一种众所周知的经过同行评审的已发布算法。使用现成的封闭源代码库是个坏主意，算法可能很棒，但你不知道它们有什么后门。
他也没有说他使用的是什么链接模式。使用公认的安全密码很容易，但仍然可以构建不安全的密码系统。

【解决方案4】：

阅读：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

【讨论】：