Java vs. Golang for HOTP (rfc-4226)

Question

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?

Kimbrakimbrell

Answer 1

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 

Guelders

wow - TIL! what would the inverse operation be? (taking the Go version and creating the java version). Thanks a lot! – Kimbrakimbrell

@ZachKauffman: it's the same data, it's just the difference between interpreting it as signed or unsigned. – Verrocchio

@ZachKauffman Yes, to display a Go byte value in a signed fashion, just convert it to int8. See edited answer. – Guelders

Awesome! Guess I need to brush up on my fundamentals a bit (pun intended). It looks like changing my return from base64.StdEncoding.EncodeToString(h.Sum(nil)) to hex.EncodeToString(h.Sum(nil)) in the Go version solved the problem. – Kimbrakimbrell

@ZachKauffman Base64 and hex encoding are quite different things (giving completely different result). So basically the long -> byte array conversion is right in your case, but in your examples the counter value was different. – Guelders