我正在尝试在 Golang 中实现 HOTP (rfc-4226),并且正在努力生成有效的 HOTP.我可以在 java 中生成它,但由于某种原因,我在 Golang 中的实现有所不同.以下是示例:
I'm trying to implement HOTP (rfc-4226) in Golang and I'm struggling to generate a valid HOTP. I can generate it in java but for some reason my implementation in Golang is different. Here are the samples:
public static String constructOTP(final Long counter, final String key)
throws NoSuchAlgorithmException, DecoderException, InvalidKeyException {
final Mac mac = Mac.getInstance("HmacSHA512");
final byte[] binaryKey = Hex.decodeHex(key.toCharArray());
mac.init(new SecretKeySpec(binaryKey, "HmacSHA512"));
final byte[] b = ByteBuffer.allocate(8).putLong(counter).array();
byte[] computedOtp = mac.doFinal(b);
return new String(Hex.encodeHex(computedOtp));
}
在 Go 中:
func getOTP(counter uint64, key string) string {
str, err := hex.DecodeString(key)
if err != nil {
panic(err)
}
h := hmac.New(sha512.New, str)
bs := make([]byte, 8)
binary.BigEndian.PutUint64(bs, counter)
h.Write(bs)
return base64.StdEncoding.EncodeToString(h.Sum(nil))
}
我认为问题在于 Java 行:ByteBuffer.allocate(8).putLong(counter).array();
生成的字节数组与 Go 行不同:binary.BigEndian.PutUint64(bs, counter)
.
I believe the issue is that the Java line: ByteBuffer.allocate(8).putLong(counter).array();
generates a different byte array than the Go line: binary.BigEndian.PutUint64(bs, counter)
.
在 Java 中,生成以下字节数组:83 -116 -9 -98 115 -126 -3 -48
而在 Go 中:83 140 247 158 115 130 253 207代码>.
In Java, the following byte array is generated: 83 -116 -9 -98 115 -126 -3 -48
and in Go: 83 140 247 158 115 130 253 207
.
有人知道这两条线的区别以及如何移植 java 线吗?
Does anybody know the difference in the two lines and how I can port the java line to go?
Java中的byte
类型是有符号的,它的范围是-128..127
,而在 Go 中,byte
是 uint8
的别名,范围为 0..255
.所以如果你想比较结果,你必须将Java的负值移动256
(添加256
).
The byte
type in Java is signed, it has a range of -128..127
, while in Go byte
is an alias of uint8
and has a range of 0..255
. So if you want to compare the results, you have to shift negative Java values by 256
(add 256
).
提示:要以无符号方式显示 Java byte
值,请使用:byteValue &0xff
使用 byte
的 8 位作为 int
中的最低 8 位将其转换为 int
.或者更好:以十六进制形式显示两个结果,这样您就不必关心符号...
Tip: To display a Java byte
value in an unsigned fashion, use: byteValue & 0xff
which converts it to int
using the 8 bits of the byte
as the lowest 8 bits in the int
. Or better: display both results in hex form so you don't have to care about sign-ness...
将 256 添加到负 Java 字节值,输出几乎与 Go 相同:最后一个字节减 1:
Adding 256 to your negative Java byte values, the output is almost identical to Go's: the last byte is off by 1:
javabytes := []int{83, -116, -9, -98, 115, -126, -3, -48}
for i, b := range javabytes {
if b < 0 {
javabytes[i] += 256
}
}
fmt.Println(javabytes)
输出是:
[83 140 247 158 115 130 253 208]
因此,Java 数组的最后一个字节是 208
,而 Go 数组的最后一个字节是 207
.我猜您的 counter
会在您未发布的代码中的其他地方增加一次.
So the last byte of your Java array is 208
while Go's is 207
. I'm guessing your counter
is incremented once somewhere else in your code which you haven't posted.
不同的是,在 Java 中返回的是十六进制编码的结果,而在 Go 中返回的是 Base64 编码的结果(它们是两种不同的编码,给出完全不同的结果).正如您所确认的,在返回 hex.EncodeToString(h.Sum(nil))
的 Go 中,结果匹配.
What differs is that in Java you return the hex encoded result while in Go you return the Base64 encoded result (they are 2 different encodings giving entirely different results). As you confirmed, in Go returning hex.EncodeToString(h.Sum(nil))
the results match.
提示 #2:要以签名方式显示 Go 的字节,只需将它们转换为 int8
(已签名),如下所示:
Tip #2: To display Go's bytes in a signed fashion, simply convert them to int8
(which is signed) like this:
gobytes := []byte{83, 140, 247, 158, 115, 130, 253, 207}
for _, b := range gobytes {
fmt.Print(int8(b), " ")
}
这个输出:
83 -116 -9 -98 115 -126 -3 -49
这篇关于用于 HOTP 的 Java 与 Golang (rfc-4226)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持html5模板网!