在AES加密中使用带有NoPadding的CBC是否正确？ [英] Is correct to use CBC with NoPadding in AES Encryption?
问题描述
我目前正在使用mcrypt.java来对服务器端和客户端的cryptojs进行数据加密和解密，但是我遇到了一些问题，因为当我加密任何字符串时，java和JavaScript都会显示不同的结果。
好吧，我正在阅读有关AES加密的方法和填充方案的信息，有些博客在谈论在NoPadding上使用CBC模式是不正确的，在Pkcs7或其他填充上使用CBC是更好/正确的方法。 / p>
任何人都可以向我解释与此相关的东西吗？
填充您的如果您以ECB / CBC块密码模式执行AES加密，则需要纯文本，除非您的纯文本是块大小的倍数。当然，您可以确保纯文本始终精确地为N个块，但实际上您将创建自己的填充模式。
许多库（例如PHP中的mcrypt）在他们秘密执行填充时，请勿指定任何填充。他们只是用 00 个值字节填充了最后一个块。这样的效果是，您可以加密 ASCII兼容文本，然后该文本将为空终止。在大多数语言（不使用空终止）中，也可以使用 trim 方法删除此填充。但是，这不是官方的填充模式。当然，该方案仅在您的纯文本不以控制字符结尾的情况下有效。因此，它不适合任何二进制明文。
使用PKCS＃7填充绝对更好。对于 any 纯文本，删除PKCS＃7填充是确定性的。这意味着您可以加密任何值，包括UTF-16编码的文本和任何二进制值。如果PKCS＃7填充不可用，则您自己实现它相对容易-这当然值得付出努力。用于CBC模式的PKCS＃7填充的唯一缺点是，当明文已经是块大小的N倍时，它可能需要附加的填充块。原因是否则明文可能会被误认为是填充。
请注意，填充和填充错误不适合来检测是否密文在传输中已更改。填充Oracle非常易于实现，并且可以以以字节为单位的纯文本大小的128倍显示您的纯文本（!!!）。因此，如果您想为纯文本提供完整性和真实性，请使用经过身份验证的操作模式或MAC（HMAC或CMAC）。
如果您确实不能错过所使用的字节对于填充，请查看块密码的CTR或类似的流操作模式。
编辑
还有密文盗用或CTS，可用于CBC模式。它使用不多，并且有三种不同版本，因此应确保使用了哪个版本。
如今，使用计数器模式（点击率）更为普遍模式）或基于此模式的身份验证模式（如果完全使用分组密码）。点击率模式不需要任何填充，因为它是一种流式操作模式。
I'm currently working with mcrypt.java To encrypt and decrypt data from server side and cryptojs on client side but I have some problems because when I encrypt any string, both java and JavaScript display different results.
Well, I was reading about methods and padding schemes of AES encryption and some blogs talking about is incorrect to use CBC mode with NoPadding and is better/correct use CBC with Pkcs7 or another padding.
Anyone can explain me something related with that?
Padding your plaintext is required if you perform AES encryption in ECB/CBC block cipher mode, unless your plaintext is a multiple of the blocksize. You could of course make sure that your plaintext is always precisely N blocks, but in effect you would be creating your own padding mode.
Many libraries (e.g. mcrypt in PHP) don't specify any padding while they secretly do pad. They just fill up the last block with 00 valued bytes. The effect of this is that you can encrypt ASCII compatible text, which will then be null terminated. In most languages (that do not use null termination) it is also possible to use a trim method to remove this padding. This is however not an official padding mode. Of course this scheme only works if your plain text does not end with control characters. So it is not suitable for any binary plaintext.
It is definitely better to use PKCS#7 padding. Removing PKCS#7 padding is deterministic for any plaintext. This means you can encrypt any value, including UTF-16 encoded text and any binary value. If PKCS#7 padding is not available it is relatively easy to implement it yourself - this is certainly worth the effort. The only disadvantage of PKCS#7 padding for CBC mode is that it may require an additional block of padding when the plaintext is already N times the block size. The reason for this is that the plaintext may otherwise be misinterpreted as being padding.
Note that padding and padding errors are not suitable to detect if the ciphertext was changed in transit. Padding Oracles are very easy to implement and may reveal your plaintext in 128 times the size of your plaintext in bytes (!!!). So use an authenticated mode of operation or a MAC (HMAC or CMAC) if you want to provide integrity and authenticity to your plaintext.
If you really cannot miss the bytes used for padding, please look at CTR or a similar stream mode of operation for your block cipher.
EDIT
there is also ciphertext stealing or CTS that can be used for CBC mode. It is not used much and as there are three different versions of it, you should make sure which one is used.
Nowadays it is more common to use counter mode (CTR mode) or an authenticated mode which is based on it (if a block cipher is used at all). CTR mode doesn't require any padding as it is a streaming mode of operation.
这篇关于在AES加密中使用带有NoPadding的CBC是否正确？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
