检测使用 AES CBC 加密的文本是否被填充答案

【问题标题】：Detect if a text encrypted using AES CBC is padded or not检测使用 AES CBC 加密的文本是否被填充
【发布时间】：2021-06-08 17:05:10
【问题描述】：

我有一些可以使用AES/CBC/NoPadding 或AES/CBC/PKCS5Padding 加密的数据。

我想解密该数据。因此需要决定使用哪种算法进行解密。根据数据，是否可以确定加密的数据是否被填充？还是有其他解决方案？

【问题讨论】：

不，至少先验明文的长度是不可能的。
使用 NoPadding 解密。然后查看解密文本的结尾。如果有填充，那就是它出现的地方。您可以检查它以确定在加密方面使用了哪种填充。如果它最初是用 NoPadding 加密的，那么解密后的文本将正常结束，并且最后添加的填充中没有奇怪的字符。
@rossum：没有办法区分填充的纯文本和恰好具有相同字符的未填充的纯文本，除非“没有奇怪的字符”是指 ASCII 文本。
如果 NoPadding 解密后的文本以 0x03 0x03 0x03 结尾，那么很可能是 3 个字节的 PKCS7 填充。如果它以 0x00 0x00 0x00 0x00 ... 结尾，那么它很可能是 PaddingZeros。你不能绝对肯定，但你可以做出有根据的猜测。

标签： encryption cryptography cypher aes

【解决方案1】：

cmets 是正确的，但是在编程方面有更好的方法； bad padding exception（假设是 Java）

try {
     
     //do the decryption....

    } catch (javax.crypto.BadPaddingException e ){
          Sytem.out.Println("It is not PKCS#7 padding")
          e.printStackTrace();

    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }

如果出现异常，则不是 PKCS#7。如果您没有遇到异常，那么您有 1/256 的概率不是 PKCS#7，但您的文件以字节 0x01 结尾。还有其他情况，例如您的文件以0x0202 结尾，但是，概率非常低，其他情况也低于此。最简单的方法是尝试多个文件。

我为什么说PKCS#7 padding 很简单。尽管 Java 说不是 PKCS#5 填充，但它是 PKCS#7 填充取代了 #5。 #5 是为 DES 等 64 位块大小的密码设计的，而 #7 被设计为高达 256 字节，其中 AES 具有 128 位块大小。

请注意，概率是假设文件是随机的，而不是常规的文本文件。

【讨论】：

感谢您的回复。你知道为什么在少数情况下不抛出 BadPaddingException 吗？就我而言，我有很多数据要解密。我听从了您的建议，并观察到在少数情况下，解密的数据比应有的小一个字节。
你读过第一段吗？不清楚吗？如果最后一个字节是0x01，那么它是 PKCS#7 的有效填充。在 1/256 的情况下（如果数据统一随机），尽管数据未填充，但您将获得有效的填充。