填充 - 加密算法
我正在编写一个适用于“流”的 XXTEA 加密算法的实现，即可以像这样使用： crypt mykey < 我的文件> 输出。
必要条件之一是它根本无法访问该文件（它只读取固定大小的块，直到找到 EOF）。 该算法要求数据字节是4的倍数，因此需要添加填充。
对于纯文本，一个好的解决方案是用 NULL 填充，并在解密时忽略 NULL，但相同的策略不能用于二进制流（可以包含嵌入的 NULL）。
我已经阅读了常见的解决方案，例如用缺少的字符数填充（如果缺少 3 个字符，则在末尾附加 3, 3, 3）等，但我想知道：还有更优雅的解决方案吗？
I'm writing an implementation of the XXTEA encryption algorithm that works on "streams", ie, can be used like: crypt mykey < myfile > output.
One of the requisites is that it doesn't have access to the file at all (it only reads an fixed size block until find an EOF). The algorithm needs that the data bytes is multiple of 4, so its needed to add a padding.
For plain text a good solution is to pad with NULLs, and in the decryption just ignore the NULLs, but the same strategy cannot be used for binary streams (that can contain embedded NULLs).
I've read the common solutions, like padding with the number of missing chars (if it miss 3 chars, then append an 3, 3, 3 at the end) and etc, but I wonder: theres a more elegant solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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
Read: http://msdn.microsoft.com/en-us/library/system.security.cryptography.paddingmode.aspx
It has a list of common padding methods, like:
PKCS7 - The PKCS #7 padding string consists of a sequence of bytes, each of which is equal to the total number of padding bytes added.
The ANSIX923 padding string consists of a sequence of bytes filled with zeros before the length.
The ISO10126 padding string consists of random data before the length.
Examples:
Raw data: 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
阅读密文窃取。 它可以说比纯文本填充优雅得多。 另外，我建议使用大于 4 字节的块大小——64 位可能是最低限度。
严格来说，DIY 密码学是一个危险的想法。 整个加密社区都尝试过但未能破解的算法很难被击败。 玩得开心，并考虑阅读此，或者至少是 Schneier 的“相关内容”阅读”部分。
Read up on ciphertext stealing. It's arguably much more elegant than plaintext padding. Also, I'd suggest using a block size larger than 4 bytes -- 64 bits is probably the bare minimum.
Strictly speaking, do-it-yourself cryptography is a dangerous idea; it's hard to beat algorithms that the entire crypto community has tried and failed to break. Have fun, and consider reading this, or at least something from Schneier's "related reading" section.
阅读这个问题，看起来这个问题的安全方面是没有意义的。 简而言之，您有一个 api 需要 4 字节的倍数作为输入，但您并不总是这样。
如果您不能保证二进制流不关心，那么向任何二进制流附加最多 3 个字节是危险的。 在 exe 文件末尾添加 0 并不重要，因为 exe 文件的标头指定了所有剩余位的相关大小。 将 0 附加到 pcx 文件的末尾会破坏它，因为 pcx 文件的标头从文件末尾开始特定数量的字节。
所以实际上你别无选择 - 无法选择可以使用的神奇填充字节，这些字节保证永远不会自然出现在二进制流的末尾：你必须始终附加至少一个额外的双字描述所使用的填充字节的信息。
Reading the question it looks like the security aspect of this is moot. Simply put, you have an api that expects a multiple of 4 bytes as input, which you dont always have.
Appending up to 3 bytes onto any binary stream is dangerous if you can't make guarantees that the binary stream doesn't care. Appending 0's onto the end of an exe file doesnt matter as exe files have headers specifying the relevent sizes of all remaining bits. Appending 0's onto the end of a pcx file would break it as pcx files have a header that starts a specific number of bytes from the end of the file.
So really you have no choice - there are no choice of magic padding bytes you can use that are guaranteed to never occur naturally at the end of a binary stream: You must always append at least one additional dword of information describing the padding bytes used.
实际上，我希望一个好的流密码根本不需要填充。 例如，RC4 不需要填充，是一种非常强大的流密码。 但是，如果攻击者可以将不同的选择数据提供给始终使用相同密钥并且还可以访问加密数据的加密例程，则可能会受到攻击。 选择正确的输入数据并分析输出数据可用于恢复加密密钥，无需暴力攻击； 但除此之外，RC4 非常安全。
如果需要填充，则恕我直言，它不是流密码。 就好像你pad成4字节的倍数或者16字节的倍数，有什么巨大的区别呢？ 如果将其填充为 16 字节的倍数，则您几乎可以使用任何分组密码。 实际上你的密码是一个分组密码，它只适用于 4 字节块。 它是系统上的流密码，其中每个“符号”都是 4 字节（例如，当加密 UTF-32 文本时，在这种情况下，数据肯定始终是 4 的倍数，因此永远不会有任何填充）。
Actually I would expect that a good stream cipher needs no padding at all. RC4 for example needs no padding and is is a very strong stream cipher. However, it can be attacked if the attacker can feed different chosen data to the encryption routine, that always uses the same key, and also has access to the encrypted data. Choosing the right input data and analyzing the output data can be used to restore the encryption key, without a brute force attack; but other than that RC4 is very secure.
If it needs padding, it is no stream cipher IMHO. As if you pad to be a multiple of 4 byte or a multiple of 16 byte, what's the huge difference? And if it is padded to be a multiple of 16 byte, you could use pretty much any block cipher. Actually your cipher is a block cipher, it just works with 4 byte blocks. It was a stream cipher on a system where every "symbol" is 4 byte (e.g. when encryption UTF-32 text, in which case the data will always be a multiple of 4 for sure, thus there is never any padding).