gpt4 book ai didi

encryption - AES PKCS7填充

转载 作者:行者123 更新时间:2023-12-04 14:43:51 28 4
gpt4 key购买 nike

我刚刚开始学习Bouncy CaSTLe,进行AES加密/解密。我正在将AES/CBC/PKCS7PADDING与256位 key 一起使用。

BC可以成功地加密和解密文本,但是在解密之后,我注意到总是有一些填充空(0x00),因此我的哈希比较失败了。例如,假设原始输入字符串为“1234567890”,则解密的字节数组始终为:

{0x49,0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x48,0x00,0x00,0x00,0x00,0x00,0x00}

为什么填充不是 0x06,0x06,0x06,0x06,0x06,0x06?还有什么方法可以确定性地告知加密后的填充长度(可以为0),以便在加密之前可以得到完全相同的字符串?

最佳答案

当您指定 PKCS7 时, BC 将在加密之前将填充添加到数据中,并在解密时再次将其删除。带有 PKCS7 AES 将始终添加至少1个字节的填充,并将添加足够的数据以使输入成为AES块大小的倍数。在对填充进行解密时,会验证是正确的,并且在PKCS7的情况下,它还可以指示最后一块解密数据中的填充是多少,以及实际数据是多少。

如果尝试在解密步骤中未指定PKCS7的情况下解密加密和填充的数据,则填充仍将存在于解密的数据中。

编辑:

为了说明我的观点,这是一些Java代码,它们使用 AES/CBC/PKCS7 加密“1234567890”,然后在有和没有PKCS7填充的情况下再次对其解密:

public class BCTest {
public static void doTest() throws Exception {
Security.addProvider(new BouncyCastleProvider());

byte[] clearData = "1234567890".getBytes();
SecretKey secretKey = new SecretKeySpec("0123456789ABCDEF".getBytes(), "AES");
AlgorithmParameterSpec IVspec = new IvParameterSpec("0123456789ABCDEF".getBytes());

// encrypt with PKCS7 padding
Cipher encrypterWithPad = Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC");
encrypterWithPad.init(Cipher.ENCRYPT_MODE, secretKey, IVspec);
byte[] encryptedData = encrypterWithPad.doFinal(clearData);
System.out.println("Encryped data (" + encryptedData.length + " bytes): \t" + toHexString(encryptedData));

// decrypt with PKCS7 pad
Cipher decrypterWithPad = Cipher.getInstance("AES/CBC/PKCS7PADDING", "BC");
decrypterWithPad.init(Cipher.DECRYPT_MODE, secretKey, IVspec);
byte[] buffer1 = new byte[encryptedData.length];
int decryptLen1 = decrypterWithPad.doFinal(encryptedData, 0, encryptedData.length, buffer1);
System.out.println("Decrypted with Pad (" + decryptLen1 + " bytes): \t" + toHexString(buffer1));

// decrypt without PKCS7 pad
Cipher decrypterWithoutPad = Cipher.getInstance("AES/CBC/NOPADDING", "BC");
decrypterWithoutPad.init(Cipher.DECRYPT_MODE, secretKey, IVspec);
byte[] buffer2 = new byte[encryptedData.length];
int decryptLen2 = decrypterWithoutPad.doFinal(encryptedData, 0, encryptedData.length, buffer2);
System.out.println("Decrypted without Pad (" + decryptLen2 + " bytes):\t" + toHexString(buffer2));
}

private static String toHexString(byte[] bytes) {
return javax.xml.bind.DatatypeConverter.printHexBinary(bytes);
}

public static void main(String[] args) throws Exception {
BCTest.doTest();
}
}

输出:

Encryped data (16 bytes):           602CAE14358D0AC5C96E2D46D17E58E3
Decrypted with Pad (10 bytes): 31323334353637383930000000000000
Decrypted without Pad (16 bytes): 31323334353637383930060606060606

当使用padding选项进行解密时,输出已被填充了 strip 化-密码指示10字节的解密数据-缓冲区的其余部分为0填充。没有填充选项的解密将导致填充现在成为解密数据的一部分。

编辑2:

现在看到原始代码,证实了我的直觉。 GetOutputSize方法不返回解密字符串的输出大小,而仅返回输出缓冲区中所需的最大空间。该方法在BC代码中具有以下文档:

/**
* return the size of the output buffer required for an update plus a
* doFinal with an input of len bytes.
*
* @param len the length of the input.
* @return the space required to accommodate a call to update and doFinal
* with len bytes of input.
*/

DoFinal返回放入缓冲区的解密数据的实际长度。

所以在

byte[] plainTextBuffer = new byte[cipher.GetOutputSize(data.Length - IV_LENGTH)];
int length = cipher.DoFinal(data, iv.Length, data.Length - iv.Length, plainTextBuffer, 0);
plainTextBuffer将比实际解密的数据稍大-数据的实际长度将在 length中。

关于encryption - AES PKCS7填充,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28592989/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com