doudu5029 2017-12-13 15:47
浏览 104
已采纳

Java与Golang for HOTP(RFC-4226)

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));
}

and in 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))
}

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).

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.

Does anybody know the difference in the two lines and how I can port the java line to go?

  • 写回答

1条回答 默认 最新

  • dsf6565 2017-12-13 15:49
    关注

    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).

    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...

    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)
    

    Output is:

    [83 140 247 158 115 130 253 208]
    

    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.

    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.

    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), " ")
    }
    

    This outputs:

    83 -116 -9 -98 115 -126 -3 -49 
    
    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 求差集那个函数有问题,有无佬可以解决
  • ¥15 MATLAB动图问题
  • ¥15 【提问】基于Invest的水源涵养
  • ¥20 微信网友居然可以通过vx号找到我绑的手机号
  • ¥15 寻一个支付宝扫码远程授权登录的软件助手app
  • ¥15 解riccati方程组
  • ¥15 display:none;样式在嵌套结构中的已设置了display样式的元素上不起作用?
  • ¥15 使用rabbitMQ 消息队列作为url源进行多线程爬取时,总有几个url没有处理的问题。
  • ¥15 Ubuntu在安装序列比对软件STAR时出现报错如何解决
  • ¥50 树莓派安卓APK系统签名