我的公司正在开展一个将读卡器投入使用的项目。读卡器使用 DUKPT TripleDES 加密，因此我们需要开发软件来解密我们服务器上的卡数据。
我刚刚开始触及这个问题的表面，但我发现自己陷入了一个看似简单的问题......试图生成 IPEK(重新创建对称 key 的第一步)。
IPEK 是通过连接两个三重 DES 加密的 8 字节十六进制字符串创建的 16 字节十六进制值。
我已经尝试了带和不带填充的 ECB 和 CBC(IV 为零)模式，但是当我需要与输入大小相同的结果时，每个单独编码的结果总是 16 个字节或更多(2 个或更多块)。事实上，在整个过程中，密文应该与被编码的明文大小相同。
<cfset x = encrypt("FFFF9876543210E0",binaryEncode(binaryDecode("0123456789ABCDEFFEDCBA98765432100123456789ABCDEF", "hex"), "base64") ,"DESEDE/CBC/PKCS5Padding","hex",BinaryDecode("0000000000000000","hex"))>
结果:3C65DEC44CC216A686B2481BECE788D197F730A72D4A8CDD
如果使用 NoPadding 标志，结果是:
3C65DEC44CC216A686B2481BECE788D1
我还尝试将纯文本十六进制消息编码为 base64(就像 key 一样)。在上面的示例中，返回结果为:
DE5BCC68EB1B2E14CEC35EB22AF04EFC。
如果您执行相同操作，但不使用 NoPadding 标志，则会出现“输入长度不是 8 字节的倍数”的错误。
我是密码学的新手，所以希望我在这里犯了一些非常基本的错误。为什么这些分组密码算法生成的密文与明文消息的长度不一样？
对于更多背景知识，作为“通过它”练习，我一直在尝试复制此处列出的工作:
https://www.parthenonsoftware.com/blog/how-to-decrypt-magnetic-stripe-scanner-data-with-dukpt/
最佳答案
我不确定它是否相关并且它可能不是您正在寻找的答案，但我花了一些时间测试错误 ID 3842326 .当使用不同的属性时，CF 在后台以不同的方式处理种子和盐。例如，如果您传入一个变量作为要加密的字符串而不是常量(函数调用中的硬编码字符串)，则结果字符串每次都会更改。这可能表示不同的方法签名 - 在你的示例中，一个标志与另一个标志你看到了类似的东西。
Adobe 的回应是，鉴于在任何一种情况下都可以对结果字符串进行解密，这并不是真正的错误 - 更多的是需要注意的行为。你得到的字符串可以不加密吗？
关于encryption - 使用 Coldfusion 的 Encrypt 函数加密一个十六进制 block 并返回一个 block 长度结果，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27381929/