CCCrypt 填充选项似乎不影响解密
CCCrypt padding option doesn't seem to affect decryption
我有一个使用 Java
加密的字符串
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key);
return cipher.doFinal(text.getBytes());
(注意在Java中,使用AES时PKCS5Padding实际上是PKCS7Padding link)
而我的解密内码是:
CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt,
kCCAlgorithmAES128,
0,
key.bytes,
kCCBlockSizeAES128,
iv.bytes,
[encrypted bytes],
dataLength,
buffer,
bufferSize,
&numBytesEncrypted);
像这样称呼:
let decryptedData = decryptor.AES128DecryptWithKeyString(key, encryptedString: encodedString) //this does the CCCrypt stuff
let string:NSString = NSString(data: decryptedData, encoding: NSUTF8StringEncoding) ?? ""
let data = NSData(base64EncodedString: string as String, options: NSDataBase64DecodingOptions.IgnoreUnknownCharacters)
因此,尽管它是使用 PKCS5Padding 加密的,但我的解密工作正常,尽管没有提供填充选项。此外,如果我将 0
选项更改为 kCCOptionPKCS7Padding
,它也可以解密。
这是预期的行为吗?填充选项是否仅与 kCCEncrypt 相关,与 kCCDecrypt 无关?
此外,如果我们将 Java 加密更改为
Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
并用零字节手动填充有效负载,然后无论我使用 0
作为选项还是 kCCOptionPKCS7Padding
它仍然可以正确解密
当你说填充不影响解密时,你是在看十六进制转储中的输出吗?
填充将是 0x01
到 0x10
范围内的尾随字符,这些字符是非打印 ASCII 字符,因此在打印已使用 PKCS#7 加密的字符串时看起来是一样的填充但使用填充选项解密。
将两种方式的样本输出作为十六进制转储添加到问题中,您应该会看到真正发生的事情。
return 状态不表示正确解密或无效填充,仅表示严重的调用错误。
示例:
let keyData = Array("12345678901234567890123456789012".utf8)
let messageData = Array("Don´t try".utf8)
let encrypted = testCrypt(data:messageData, keyData:keyData, operation:kCCEncrypt, options:UInt32(kCCOptionPKCS7Padding))!
print("encrypted: \(encrypted)")
let decryptedPKCS7 = testCrypt(data:encrypted, keyData:keyData, operation:kCCDecrypt, options:UInt32(kCCOptionPKCS7Padding))!
print("decrypted PKCS7: \(decryptedPKCS7)")
let decryptedNone = testCrypt(data:encrypted, keyData:keyData, operation:kCCDecrypt, options:UInt32(0))!
print("decrypted None: \(decryptedNone)")
Output:
encrypted: [136, 95, 194, 76, 137, 107, 196, 39, 245, 108, 106, 84, 139, 49, 14, 139]
decrypted PKCS7: [68, 111, 110, 194, 180, 116, 32, 116, 114, 121]
decrypted None: [68, 111, 110, 194, 180, 116, 32, 116, 114, 121, 6, 6, 6, 6, 6, 6]
后面的六个 0x06
字节是未删除的填充。
我有一个使用 Java
加密的字符串Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(Cipher.ENCRYPT_MODE, key);
return cipher.doFinal(text.getBytes());
(注意在Java中,使用AES时PKCS5Padding实际上是PKCS7Padding link)
而我的解密内码是:
CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt,
kCCAlgorithmAES128,
0,
key.bytes,
kCCBlockSizeAES128,
iv.bytes,
[encrypted bytes],
dataLength,
buffer,
bufferSize,
&numBytesEncrypted);
像这样称呼:
let decryptedData = decryptor.AES128DecryptWithKeyString(key, encryptedString: encodedString) //this does the CCCrypt stuff
let string:NSString = NSString(data: decryptedData, encoding: NSUTF8StringEncoding) ?? ""
let data = NSData(base64EncodedString: string as String, options: NSDataBase64DecodingOptions.IgnoreUnknownCharacters)
因此,尽管它是使用 PKCS5Padding 加密的,但我的解密工作正常,尽管没有提供填充选项。此外,如果我将 0
选项更改为 kCCOptionPKCS7Padding
,它也可以解密。
这是预期的行为吗?填充选项是否仅与 kCCEncrypt 相关,与 kCCDecrypt 无关?
此外,如果我们将 Java 加密更改为
Cipher cipher = Cipher.getInstance("AES/CBC/NoPadding");
并用零字节手动填充有效负载,然后无论我使用 0
作为选项还是 kCCOptionPKCS7Padding
当你说填充不影响解密时,你是在看十六进制转储中的输出吗?
填充将是 0x01
到 0x10
范围内的尾随字符,这些字符是非打印 ASCII 字符,因此在打印已使用 PKCS#7 加密的字符串时看起来是一样的填充但使用填充选项解密。
将两种方式的样本输出作为十六进制转储添加到问题中,您应该会看到真正发生的事情。
return 状态不表示正确解密或无效填充,仅表示严重的调用错误。
示例:
let keyData = Array("12345678901234567890123456789012".utf8)
let messageData = Array("Don´t try".utf8)
let encrypted = testCrypt(data:messageData, keyData:keyData, operation:kCCEncrypt, options:UInt32(kCCOptionPKCS7Padding))!
print("encrypted: \(encrypted)")
let decryptedPKCS7 = testCrypt(data:encrypted, keyData:keyData, operation:kCCDecrypt, options:UInt32(kCCOptionPKCS7Padding))!
print("decrypted PKCS7: \(decryptedPKCS7)")
let decryptedNone = testCrypt(data:encrypted, keyData:keyData, operation:kCCDecrypt, options:UInt32(0))!
print("decrypted None: \(decryptedNone)")
Output:
encrypted: [136, 95, 194, 76, 137, 107, 196, 39, 245, 108, 106, 84, 139, 49, 14, 139] decrypted PKCS7: [68, 111, 110, 194, 180, 116, 32, 116, 114, 121] decrypted None: [68, 111, 110, 194, 180, 116, 32, 116, 114, 121, 6, 6, 6, 6, 6, 6]
后面的六个 0x06
字节是未删除的填充。