【问题标题】:Java Mac HMAC vs C++ OpenSSL hmacJava Mac HMAC 与 C++ OpenSSL hmac
【发布时间】:2016-02-07 14:21:03
【问题描述】:

这将是一个很长的问题,但我有一个非常奇怪的错误。我在 C++ 中使用 OpenSSL 来计算 HMAC,并将它们与使用 javax.crypto.Mac 的类似实现进行比较。对于某些密钥,HMAC 计算是正确的,而对于其他密钥,HMAC 存在差异。我相信当钥匙变大时会出现问题。以下是详细信息。

这是 C++ 最重要的代码:

void computeHMAC(std::string message, std::string key){
    unsigned int digestLength = 20;
    HMAC_CTX hmac_ctx_;
    BIGNUM* key_ = BN_new();;

    BN_hex2bn(&key_, key); 

    unsigned char convertedKey[BN_num_bytes(key_)];
    BIGNUM* bn = BN_new();

    HMAC_CTX_init(&hmac_ctx_);

    BN_bn2bin(bn, convertedKey);
    int length = BN_bn2bin(key_, convertedKey);

    HMAC_Init_ex(&hmac_ctx_, convertedKey, length, EVP_sha1(), NULL);

/*Calc HMAC */
    std::transform( message.begin(), message.end(), message.begin(), ::tolower);
    unsigned char digest[digestLength];

    HMAC_Update(&hmac_ctx_, reinterpret_cast<const unsigned char*>(message.c_str()),
      message.length());
    HMAC_Final(&hmac_ctx_, digest, &digestLength);
    char mdString[40];
    for(unsigned int i = 0; i < 20; ++i){
        sprintf(&mdString[i*2], "%02x", (unsigned int)digest[i]);
    }
     std::cout << "\n\nMSG:\n" << message << "\nKEY:\n" + std::string(BN_bn2hex(key_)) + "\nHMAC\n" + std::string(mdString) + "\n\n";
}

java 测试如下:

public String calculateKey(String msg, String key) throws Exception{

    HMAC = Mac.getInstance("HmacSHA1");

    BigInteger k = new BigInteger(key, 16);

    HMAC.init(new SecretKeySpec(k.toByteArray(), "HmacSHA1"));

    msg = msg.toLowerCase();
    HMAC.update(msg.getBytes());
    byte[] digest = HMAC.doFinal();

    System.out.println("Key:\n" + k.toString(16) + "\n");
    System.out.println("HMAC:\n" + DatatypeConverter.printHexBinary(digest).toLowerCase() + "\n");

    return DatatypeConverter.printHexBinary(digest).toLowerCase();
}

一些测试使用不同的键运行(所有字符串都被解释为十六进制):


键 1: 736A66B29072C49AB6DC93BB2BA41A53E169D14621872B0345F01EBBF117FCE48EEEA2409CFC1BD92B0428BA0A34092E3117BEB4A8A14F03391C661994863DAC1A75ED437C1394DA0741B16740D018CA243A800DA25311FDFB9CA4361743E8511E220B79C2A3483FCC29C7A54F1EB804481B2DC87E54A3A7D8A94253A60AC77FA4584A525EDC42BF82AE2A1FD6E3746F626E0AFB211F6984367B34C954B0E08E3F612590EFB8396ECD9AE77F15D5222A6DB106E8325C3ABEA54BB59E060F9EA0 P>

消息: 测试

Hmac OpenSSL: b37f79df52afdbbc4282d3146f9fe7a254dd23b3

Hmac Java Mac: b37f79df52afdbbc4282d3146f9fe7a254dd23b3


键2:636A66B29072C49AB6DC93BB2BA41A53E169D14621872B0345F01EBBF117FCE48EEEA2409CFC1BD92B0428BA0A34092E3117BEB4A8A14F03391C661994863DAC1A75ED437C1394DA0741B16740D018CA243A800DA25311FDFB9CA4361743E8511E220B79C2A3483FCC29C7A54F1EB804481B2DC87E54A3A7D8A94253A60AC77FA4584A525EDC42BF82AE2A1FD6E3746F626E0AFB211F6984367B34C954B0E08E3F612590EFB8396ECD9AE77F15D5222A6DB106E8325C3ABEA54BB59E060F9EA0 P>

消息: 测试

Hmac OpenSSL: bac64a905fa6ae3f7bf5131be06ca037b3b498d7

Hmac Java Mac: bac64a905fa6ae3f7bf5131be06ca037b3b498d7


键3:836A66B29072C49AB6DC93BB2BA41A53E169D14621872B0345F01EBBF117FCE48EEEA2409CFC1BD92B0428BA0A34092E3117BEB4A8A14F03391C661994863DAC1A75ED437C1394DA0741B16740D018CA243A800DA25311FDFB9CA4361743E8511E220B79C2A3483FCC29C7A54F1EB804481B2DC87E54A3A7D8A94253A60AC77FA4584A525EDC42BF82AE2A1FD6E3746F626E0AFB211F6984367B34C954B0E08E3F612590EFB8396ECD9AE77F15D5222A6DB106E8325C3ABEA54BB59E060F9EA0 P>

消息: 测试

Hmac OpenSSL: c189c637317b67cee04361e78c3ef576c3530aa7

Hmac Java Mac: 472d734762c264bea19b043094ad0416d1b2cd9c

如数据所示,当密钥变大时,会发生错误。如果不知道哪个实现有问题。我也尝试过使用更大的键和更小的键。我还没有确定确切的阈值。谁能发现问题?有没有人能够通过使用不同的软件进行模拟来告诉我在最后一种情况下哪个 HMAC 不正确,或者谁能告诉我我可以使用哪个第三种实现来检查我的?

亲切的问候,

罗尔风暴

【问题讨论】:

  • 我认为问题不在于密钥的长度,而在于它的符号。您能否尝试用“FF”替换其中一个短键的开始字节,看看在 C++ 和 Java 之间是否得到不同的结果?
  • 那么例如用FF替换83?
  • 这样做仍然会产生不同的 HMAC。 Openssl:53e8fab89762b945f08d245f963aab72dfd47533 Java:15996db38398cb114f73f81645d7bbb87b24c2e4
  • 不,我询问是否更换一个有效的,比如第一个或第二个,看看是否会“破坏”它。就像在第一个中将 73 替换为 FF 一样。
  • 在使用 FF 时,即使是较短的键似乎也有同样的问题。另一个奇怪的是,一些键(FF0AC77FAEFB8396CD9AE77F15D5222A6DB106E8325C3ABEA54BB5922A6A54BB59E060F9A0以前导0甚至两个前导0打印在Java版本中(如:0FF0AC77FAEFB8396CD9AE7F15D5222A6DB59E8325C396CD9AE6E8325C396CD9AB59E060F9EA0) spe>

标签: java c++ openssl hmac hmacsha1


【解决方案1】:

当您在 Java 中将十六进制字符串转换为 BigInt 时,它假定该数字为正数(除非字符串包含 - 符号)。

但它的内部表示是二进制补码。这意味着一位用于符号。

如果您要转换的值以十六进制开头,介于 007F(含)之间,那么这不是问题。它可以直接转换字节,因为最左边的位为零,这意味着该数字被认为是正数。

但是如果你转换一个以80FF 开头的值,那么最左边的位是1,这将被认为是负数。为避免这种情况,并保持BigInteger 值与提供的完全相同,它会在开头添加另一个零字节。

所以,在内部,7ABCDE 等数字的转换是字节数组

0x7a 0xbc 0xde

但是FABCDE这样的数字的转换(只是第一个字节不同!),是:

0x00 0xfa 0xbc 0xde

这意味着对于以 80-FF 范围内的字节开头的键,BigInteger.toByteArray() 生成的数组与您的 C++ 程序生成的数组不同,而是长一个字节的数组。

有几种方法可以解决这个问题 - 例如使用您自己的十六进制到字节数组解析器或在某个库中查找现有的解析器。如果你想使用BigInteger制作的那个,你可以这样做:

BigInteger k = new BigInteger(key, 16);
byte[] kByteArr = k.toByteArray();
if ( kByteArr.length > (key.length() + 1) / 2 ) {
    kByteArr = Arrays.copyOfRange(kByteArr,1,kByteArr.length);
}

现在您可以使用kByteArr 正确执行操作了。

您应该注意的另一个问题是长度奇数的键。一般来说,你不应该有一个奇数长度的十六进制八位字节字符串。像F8ACB 这样的字符串实际上是0F8ACB(不会在BigInteger 中产生额外的字节),应该这样解释。这就是我在公式中写(key.length() + 1) 的原因 - 如果密钥长度为奇数,则应将其解释为长一个八位字节。如果您编写自己的十六进制到字节数组转换器,这一点也很重要 - 如果长度是奇数,您应该在开始转换之前在开头添加一个零。

【讨论】:

  • 我明天要测试这个,因为我现在必须去,但是你可以完美地描述这个行为,所以我认为这确实是正确的答案。
  • 像魅力一样工作。如果我理解正确,您的代码正在检查生成的数组的长度是否正确。如果不是这种情况,它会将字节数组从字符 1 复制到数组末尾,从而将其缩短 1 个字节?我之前注意到前导 0,但我认为这并不重要,因为它们是 LEADING 0。
  • @RoelStorms 是的,完全正确。当您将数据视为“数字”时,前导零并不重要。但是,当您将数据仅视为要加密和解密的数据时,零就是合法的数据(例如,考虑一个黑色像素)。
猜你喜欢
  • 2015-09-07
  • 2014-08-23
  • 2012-08-01
  • 1970-01-01
  • 2011-10-26
  • 1970-01-01
  • 2012-10-12
  • 2012-11-13
  • 1970-01-01
相关资源
最近更新 更多