gpt4 book ai didi

c - Erlang 中的 AES-256/CBC 加密和 C 中的解密不起作用

转载 作者:太空宇宙 更新时间:2023-11-04 01:50:16 24 4
gpt4 key购买 nike

我在 Erlang 中加密 AES 256 位 CBC,然后在 C 代码中解密时遇到了问题。而加密/解密在 Erlang 和 C 中有效,但不能从一个到另一个。

Ivec = "1200000000000000",
Key = "586E36EEE726B37F70A6F7B770764E99",
Data = "encrypt[38ce517c95b011bbfc999f36d09e4feb92d22dd8,38ce517c95b011bbfc999f36d09e4feb92d22222]",
PaddedText = string:left(Data ++ ",",128,$0),
%%Data is "encrypt[38ce517c95b011bbfc999f36d09e4feb92d22dd8,38ce517c95b011bbfc999f36d09e4feb92d22222],0000000000000000000000000000000000000"
EncryptedText = crypto:block_encrypt(aes_cbc256, Key, Ivec, PaddedText),
%%Send to C code

C 代码

unsigned char *key = (unsigned char *)"586E36EEE726B37F70A6F7B770764E99";
unsigned char *iv = (unsigned char *)"1200000000000000";

EVP_CIPHER_CTX *ctx;
EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)
EVP_DecryptUpdate(ctx, plaintext, &len, buf, buf_len)

我得到的错误是

error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:

当我在 Erlang 中解密时,它工作正常,当我在 C 中加密时,它也可以使用相同的 key 和 IV 正常工作。是否密码模式不匹配。虽然它对我来说看起来是正确的。任何指针都会非常有用。谢谢

我发现,我在 C 中加密和解密的相同数据,然后进行了十六进制转储。 Erlang senginh 的实际加密数据为 128 字节,而由 C openssl 库加密的相同数据为 144 字节。那是正常的密文通常很长。这是输出。

加密后返回的Erlang二进制文件:

<<165,171,208,104,24,97,173,130,177,99,50,22,51,180,112,123,36,18,208,170,250,131,195,162,182,162,253,14,121,242,61,60,202,172,74,121,223,50,128,255,134,51,253,91,195,174,90,93,77,65,1,115,119,64,25,131,47,245,68,156,163,145,111,125,143,208,255,53,131,220,174,243,64,120,229,21,86,107,139,148,164,39,144,106,232,64,252,234,26,208,138,187,213,244,210,11,174,47,126,4,97,179,194,85,8,207,116,140,236,3,145,209,95,106,36,121,241,228,153,120,226,125,227,138,130,183,217,39>>

这是Erlang发送的

    Encrypted =  128

a5 ab d0 68 18 61 ad 82 b1 63 32 16 33 b4 70 7b
24 12 d0 aa fa 83 c3 a2 b6 a2 fd 0e 79 f2 3d 3c
ca ac 4a 79 df 32 80 ff 86 33 fd 5b c3 ae 5a 5d
4d 41 01 73 77 40 19 83 2f f5 44 9c a3 91 6f 7d
8f d0 ff 35 83 dc ae f3 40 78 e5 15 56 6b 8b 94
a4 27 90 6a e8 40 fc ea 1a d0 8a bb d5 f4 d2 0b
ae 2f 7e 04 61 b3 c2 55 08 cf 74 8c ec 03 91 d1
5f 6a 24 79 f1 e4 99 78 e2 7d e3 8a 82 b7 d9 27

这是相同数据的 Openssl (c) 库的输出。

Encrypted = 144

a5 ab d0 68 18 61 ad 82 b1 63 32 16 33 b4 70 7b
24 12 d0 aa fa 83 c3 a2 b6 a2 fd 0e 79 f2 3d 3c
ca ac 4a 79 df 32 80 ff 86 33 fd 5b c3 ae 5a 5d
4d 41 01 73 77 40 19 83 2f f5 44 9c a3 91 6f 7d
8f d0 ff 35 83 dc ae f3 40 78 e5 15 56 6b 8b 94
a4 27 90 6a e8 40 fc ea 1a d0 8a bb d5 f4 d2 0b
ae 2f 7e 04 61 b3 c2 55 08 cf 74 8c ec 03 91 d1
5f 6a 24 79 f1 e4 99 78 e2 7d e3 8a 82 b7 d9 27
f7 01 c0 ed 95 e3 14 e5 d2 62 21 da a9 1d 2a e7

Erlang 中缺少最后 16 个字节。我需要从 Erlang Crypto 库调用任何其他 API 吗?

最佳答案

您看到的是 padding 的差异。 OpenSSL 始终使用 PKCS#7 定义的填充方案进行填充。在 Erlang 中,您在使用密码进行加密之前用零填充明文(这称为零填充)。密码本身不会填充(看起来)。

由于明文是 16 的倍数(128 位,AES 的 block 大小),一个完整的填充 block - 由十六进制的 16 个字节组成,值为 10 - 由OpenSSL 例程。

所以如果你想匹配密文你应该使用EVP_CIPHER_CTX_set_padding(0):

EVP_CIPHER_CTX_set_padding() enables or disables padding. By default encryption operations are padded using standard block padding and the padding is checked and removed when decrypting. If the pad parameter is zero then no padding is performed, the total amount of data encrypted or decrypted must then be a multiple of the block size or an error will occur.

关于c - Erlang 中的 AES-256/CBC 加密和 C 中的解密不起作用,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44709193/

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