生成的HmacSha256签名在Java中与在Go中不同

我正在将代码从Go转换为Java。要转换的源代码位于，这是我当前转换为Java的代码

问题是我遗漏了一些东西，因为Java中生成的签名与Go中的签名不同

预期结果（如Go中的源）：

ruEWRoFO-ic-L38vTsjqIYE6DLZ532CTaZXOh1gwuVo

Java的实际结果：

x2clz4ynSxcFPNc6h3W832vyrIQ=

我的Java代码：

@Test
public void testSomeString() throws Exception {
    String signKey = "4f46feebafc4b5e988f131c4ff8b5997";
    String urlPath = "/resize";
    String urlQuery = "file=image.jpg&height=200&type=jpeg&width=300";

    byte[] signKeyAsBytes = signKey.getBytes("UTF-8");
    SecretKey SHA256_KEY = new SecretKeySpec(signKeyAsBytes, "HmacSHA256");

    byte[] hashAsBytes=Hashing.hmacSha1(SHA256_KEY)
            .newHasher()
            .putString(urlPath, UTF_8)
            .putString(urlQuery, UTF_8)
            .hash().asBytes();
    String hash = Base64.getUrlEncoder().encodeToString(hashAsBytes);

    //correct value in GoLang is: "ruEWRoFO-ic-L38vTsjqIYE6DLZ532CTaZXOh1gwuVo"
    Assert.assertEquals("ruEWRoFO-ic-L38vTsjqIYE6DLZ532CTaZXOh1gwuVo", hash);

    /*
    Junit test fails with:
    Expected :ruEWRoFO-ic-L38vTsjqIYE6DLZ532CTaZXOh1gwuVo
    Actual   :x2clz4ynSxcFPNc6h3W832vyrIQ=
    */
}

这是围棋的原版：

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/base64"
    "fmt"
)

func main() {
    fmt.Println("Hello, playground")
    signKey := "4f46feebafc4b5e988f131c4ff8b5997"
    urlPath := "/resize"
    urlQuery := "file=image.jpg&height=200&type=jpeg&width=300"

    h := hmac.New(sha256.New, []byte(signKey))
    h.Write([]byte(urlPath))
    h.Write([]byte(urlQuery))
    buf := h.Sum(nil)

    fmt.Println("sign=" + base64.RawURLEncoding.EncodeToString(buf))
}

---

我不知道您在Java中使用的是什么类，因为它不是标准类，但如果我使用标准类

javax.crypto.Mac

对该密钥和数据执行HmacSHA256（而不是HmacSHA1），并使用JSON提升的Base64的“未添加的URLsafe”变体进行编码，而不是Java默认的传统版本——我确实得到了

ruEWRoFO-ic-l38vtsjqiye6dlz532ctazxoh1gwvo

---

但是，对路径和查询进行签名而不进行一些分隔是非常糟糕的做法——这可能会允许将签名“移动”到不同的数据。使用一个只有六个字符但只有十六进制数字字符的密钥也很奇怪，尽管没有直接的危险。在没有广泛调查的情况下，我不会把这样设计的方案用于任何重要的事情

以下是最终的工作解决方案，供将来参考

package hashingImaginary;

import org.apache.commons.codec.binary.Base64;
import org.junit.Assert;
import org.junit.Test;

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class apacheHashingTest {

@Test
public void testWithJavaHmacApacheBase64() throws Exception {
    String urlPath = "/resize";
    String urlQuery = "file=image.jpg&height=200&type=jpeg&width=300";

    String signKey = "4f46feebafc4b5e988f131c4ff8b5997";
    String message = urlPath + urlQuery;

    Mac sha256_HMAC = Mac.getInstance("HmacSHA256");
    SecretKeySpec secret_key = new SecretKeySpec(signKey.getBytes(), "HmacSHA256");
    sha256_HMAC.init(secret_key);

    String hash = Base64.encodeBase64URLSafeString(sha256_HMAC.doFinal(message.getBytes()));
    System.out.println(hash);

    Assert.assertEquals("ruEWRoFO-ic-L38vTsjqIYE6DLZ532CTaZXOh1gwuVo", hash);
}
}

---

您的意思是将签名键解析为十六进制吗？现在，您正在将单个字符转换为字节，这听起来不像您想要执行的操作。据我所知，它直接从字符串转换为字节[]，而不使用base64。请参阅“[]字节（signKey）”。我知道signKey看起来像十六进制，但我相信这不是十六进制。为什么你会认为这不是十六进制？我无法想象任何程序员看到这个值而不去想“那是用十六进制编码的二进制数据”。我不熟悉Go，但这两个代码中可能存在相同的错误。是否有可能是由于在Java中调用

hmacSha1

导致的错误？我的意思是，看看生成的字符串短了多少-它看起来可能是go字符串长度的一半。您可能没有执行sha256。在Java中传递给

putString（）

的

UTF_8

值是多少？请注意，

signKey

的有效大小是128位，因为每个字符限制为4位（

0-f

）。这就是我们所说的安全缺陷。