AES 128 DOT NET et Java Compatibilité

Question

Nous avons essayé un prototype d'un système où nous chiffrons décrypter des données entre deux systèmes: un dans .NET et l'autre en Java. Nous allions utiliser le cryptage AES 128 bits simple.

Le problème que je suis confronté est trivial, mais je ne peux pas trouver une solution appropriée. Peut-être que ma compréhension de l'AES ou du chiffrement en général est moindre.

En supposant que nous ayons une clé prédéfinie, représentée par la chaîne hexadécimale suivante: "9c361fec3ac1ebe7b540487c9c25e24e". Il s'agit d'une clé de 16 octets. La partie de cryptage en Java serait

final byte[] rawKey = hexStringToByteArray("9c361fec3ac1ebe7b540487c9c25e24e"); 
    final SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES"); 
    // Instantiate the cipher 
    final Cipher cipher = Cipher.getInstance("AES"); 
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec); 

    final byte[] encrypted = cipher.doFinal(plainText.getBytes()); 

La fonction « hexStringToByteArray » convertit la chaîne hexagonale à un tableau d'octets. Le problème est que dans Java, les octets sont signés. Donc la valeur 9C est -100 et pas 156 (comme ce serait dans .NET).

En Java cela devient: -100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78

ceci est en .NET cependant: 156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78

Question: Étant donné que la représentation des clés se distingue, serait-il une incidence sur le processus de cryptage lui-même? Ceci est un cryptage simple sans CBC et PADDING.

Editer: Mise à jour du code pour qu'il soit formaté.

Answer 1

Je ne pense pas que vous avez un problème du tout. Vous avez exactement les mêmes données sur les deux plates-formes. Une version le montre comme des données signées, l'autre comme non signé ... mais les bits eux-mêmes sont les mêmes.

Je ne m'attendrais pas à ce qu'il y ait un quelconque problème à utiliser ces clés pour la cryptographie.