Implémentation Java vs Golang HOTP : pourquoi l'écart dans les valeurs générées ?

Java vs. Golang pour HOTP (rfc-4226)

Problème : différence dans la génération HOTP entre Java et Golang

En tentant d'implémenter HOTP à l'aide de Java et Golang, une différence a été remarquée dans les valeurs générées. Bien que Java ait produit avec succès un HOTP valide, l'implémentation de Golang différait.

Comprendre la différence

Le problème provient de la représentation différente des types d'octets dans Java et Go. . L'octet de Java est signé, allant de -128 à 127, tandis que l'octet de Golang est un alias de uint8, allant de 0 à 255.

Dans le code Java, la ligne ByteBuffer.allocate(8).putLong(counter ).tableau(); génère un tableau d'octets à partir de la valeur du compteur. Cependant, dans Golang, binaire.BigEndian.PutUint64(bs, counter) convertit le compteur en une représentation big-endian, ce qui donne des valeurs d'octet différentes.

Solution

Pour porter le code Java sur Go et garantir que le même tableau d'octets est généré, il faut décaler les valeurs négatives dans le tableau Java de 256 à convertissez-les en entiers non signés. Ceci peut être réalisé en utilisant le code :

for (int i = 0; i < javabytes.length; i++) {
  if (javabytes[i] < 0) {
    javabytes[i] += 256;
  }
}

De plus, notez que le code Java utilise le codage hexadécimal pour le résultat final, tandis que le code Golang utilise le codage Base64. Pour faire correspondre la sortie Java, il faut utiliser hex.EncodeToString(h.Sum(nil)) dans le code Golang.

Conseils pour le débogage

• Pour afficher les valeurs d'octets Java de manière non signée, utilisez byteValue & 0xff.
• Pour afficher les valeurs d'octets Golang de manière signée, convertissez-les en int8.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!