Encryption 无法使用SessionKey解密3DE

我正在开发一个C项目来读/写Desfire非接触式卡。 现在我实现了身份验证，我能够从卡中读取数据，但它是用3DES加密的

我想解密下一条消息：

EB 54 DF DD 07 6D 7C 0F BD D6 D1 D1 90 C6 C7 80 92 F3 89 4D 6F 16 7C BF AA 3E 7C 48 A8 71 CF A2 BD D0 43 07 1D 65 B8 7F

我的会话密钥（在身份验证步骤中生成）是：

我知道IV={0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00，0x00}

有了这些信息，我可以选择3DES，CBC模式，我可以解密消息，我有办法知道它是正确的。 它应该是，解密的：

10 1a 01 31 32 ae 03 de 39 b0 00 97 7f 65 e9 43 93 89 53 5c 9e 04 a9 3f 95 71 24 0f 0a 9b f7 ee d4 5b 1b c6 78 7a f4 36

无论如何，我尝试使用OpenSSL des库实现C代码，我发现了下一个困难：

我需要3个8字节的键，但我有一个16字节的会话键 长

我尝试将SessionKey拆分为Key1/Key2/Key1，但没有成功。 我已经读了很多关于它的书，我发现的唯一线索是我必须从我的16字节SessionKey（把它当作密码）生成这3个键，但我觉得它对我来说太高级了。 如果这是唯一的方法，是否有关于ossl密钥派生（evp_bytestokey）的教程？还有别的办法吗

谢谢 编辑： 所以，现在我处于一个非常奇怪的位置。正如你们中的许多人所注意到的，我已经从会话密钥中获取了前8个字节作为密钥3（这就是我用Key1/Key2/Key1所指的）。不管怎么说，它似乎不起作用，但有点起作用，这让我感到困惑。 我得到：

什么时候

所以我得到了预期的结果，用01对前8个字节进行XORing。这有什么意义吗？？正如OSSL docu中所说：请注意，libcrypto中同时有DES_cbc_encrypt（）和DES_ncbc_encrypt（）。我建议您只使用ncbc版本（n代表new）。请参阅OpenSSL DES手册页的BUGS部分以及这些函数的源代码。

---

但我只能访问旧版本。。。这可能是问题所在吗？

可能您不需要3个32位的键，而只需要3*32位中的一个，并且字节顺序良好

---

最好的问候

也许加密是两个密钥3DES，在这种情况下，将前8个字节、字节0-7重复为字节16-23:

44 E6 30 21 4A 89 57 38 61 7A B8 7C A9 91 B2 C0 44 E6 30 21 4A 89 57 38

有些3DES实现会自动完成，有些则必须自己完成

如果这不起作用，您需要在问题中提供更多信息。

会话密钥的大小 由于您使用的是MIFARE DESFire，并且使用的是16字节的会话密钥，因此可能使用的是2密钥三重DES。这意味着16字节的会话密钥实际上是两个密钥（8字节，或者实际上是56位，每个字节有8个未使用的“奇偶校验”位）

为了将它映射到具有3个键的3DE，只需将前8个字节附加到会话键的末尾，就可以得到

+-------------------------+-------------------------+ 16 byte session key: | 8 bytes | 8 bytes | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | +-------------------------+-------------------------+-------------------------+ 24 byte 3DES key: | 8 bytes | 8 bytes | 8 bytes | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | 44 E6 30 21 4A 89 57 38 | +-------------------------+-------------------------+-------------------------+ 通过对两个值进行XOR运算，可以计算使用的IV：

P'₀ = P₀ XOR IV P'₀ XOR P₀ = IV IV = '11 1B 00 30 33 AF 02 DF' XOR '10 1A 01 31 32 AE 03 DE' = '01 01 01 01 01 01 01 01' P'0=P0 XOR IV P'0 XOR P0=IV IV='11 1B 00 30 33 AF 02 DF'XOR'10 1A 01 31 32 AE 03 DE' = '01 01 01 01 01 01 01 01'

---

由于该IV在每个字节的LSB设置为1时完全不同，我想知道您是否意外地在IV上使用了方法

DES\u set\u odd\u parity（）

。这将解释LSB（即，如果值是DES键，则奇偶校验位）发生更改的原因。

“32位”毫无意义，DES键是8字节中的56位（忽略最低有效位），3DES密钥是24字节中的168位，两个密钥3DES密钥也是24字节中的168位，第一个和最后一个8字节是前8字节的副本。有些两个密钥3DES实现会复制前8字节，有些不会。你说得对，我使用的是DES_set_odd_奇偶校验，这就是问题所在。非常感谢！

Expected : 10 1a 01 31 32 ae 03 de de 01 00 00 00 01 01 00 14 c1 26 8f 03 20 20 41 00 30 39 01 00 00 00 00 00 00 00 00 00 00 75 b1

+-------------------------+-------------------------+ 16 byte session key: | 8 bytes | 8 bytes | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | +-------------------------+-------------------------+-------------------------+ 24 byte 3DES key: | 8 bytes | 8 bytes | 8 bytes | | 44 E6 30 21 4A 89 57 38 | 61 7A B8 7C A9 91 B2 C0 | 44 E6 30 21 4A 89 57 38 | +-------------------------+-------------------------+-------------------------+ P₀ = Dec_K(C₀) XOR IV P_n = Dec_K(C_n) XOR C_n-1 P₀ = Dec_K(C₀) XOR {0} = Dec_K(C₀) = '10 1A 01 31 32 AE 03 DE' P₀ = Dec_K(C₀) = '10 1A 01 31 32 AE 03 DE' P'₀ = Dec_K(C₀) XOR IV = '11 1B 00 30 33 AF 02 DF' P'₀ = P₀ XOR IV P'₀ XOR P₀ = IV IV = '11 1B 00 30 33 AF 02 DF' XOR '10 1A 01 31 32 AE 03 DE' = '01 01 01 01 01 01 01 01'