AES 128 DOT NET und Java-Kompatibilität

Question

Wir haben einen Prototyp eines Schemas versucht, bei dem wir Daten zwischen zwei Systemen entschlüsseln: Eine in .NET und die andere in Java. Wir wollten eine einfache 128-Bit-AES-Verschlüsselung verwenden.

Das Problem, mit dem ich konfrontiert bin, ist trivial, aber ich kann keine richtige Lösung finden. Vielleicht ist mein Verständnis von AES oder Verschlüsselung im Allgemeinen weniger.

Angenommen, wir haben einen vordefinierten Schlüssel, dargestellt durch die folgende Hex-Zeichenfolge: "9c361fec3ac1ebe7b540487c9c25e24e". Dies ist ein 16-Byte-Schlüssel. Die Teil-Verschlüsselungs in Java würde

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

Die 'hexStringToByteArray' seine Funktion wandelt den hex-String in einem Byte-Array. Das Problem ist, dass in Java Bytes signiert sind. Der Wert 9C ist also -100 und nicht 156 (wie in .NET).

In Java wird daraus: aber -100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78

In .NET, ist dies: 156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78

Frage: Da die Darstellung der Tasten selbst unterscheidet, würde es den Verschlüsselungsprozess selbst beeinflussen? Dies ist eine einfache Verschlüsselung ohne CBC und PADDING.

Bearbeiten: Aktualisierte den Code formatiert zu sehen.

Answer 1

Ich glaube nicht, dass Sie überhaupt ein Problem haben. Sie haben auf beiden Plattformen genau dieselben Daten. Eine Version zeigt es als signierte Daten, die andere als unsigned ... aber die Bits selbst sind gleich.

Ich würde nicht erwarten, dass es überhaupt ein Problem bei der Verwendung dieser Schlüssel für die Kryptographie gibt.