2017-03-15 1 views
0

Ich möchte AES-128-CBC-Verschlüsselung in JAVA und Linux tun, aber es gibt mir andere Ergebnisse. Zum Beispiel möchte ich die Zeichenfolge "my.txt" dekodieren. In Linux ich es auf diese Weise tun:AES-128-CBC ist anders in Java und Linux

echo -n my.txt | openssl aes-128-cbc -K 6f838655d1bd6312b224d3d1c8de4fe1 -iv 9027ce06e06dbc8b -a 

ich es auch zu base64 kodieren und es gibt mir dieses Ergebnis: 86M5fwdUpQ3tbFrz0ddHJw ==

in Java benutze ich diese Methode:

public static String encrypt(String key, String initVector, String value) { 
    try { 
     IvParameterSpec iv = new IvParameterSpec(initVector.getBytes("UTF-8")); 
     SecretKeySpec skeySpec = new SecretKeySpec(key.getBytes("UTF-8"), "AES"); 

     Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING"); 
     cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv); 

     byte[] encrypted = cipher.doFinal(value.getBytes()); 
     System.out.println("encrypted string: " 
       + Base64.encodeToString(encrypted, Base64.DEFAULT)); 

     return Base64.encodeToString(encrypted, Base64.DEFAULT); 
    } catch (Exception ex) { 
     ex.printStackTrace(); 
    } 

    return null; 
} 

Und mit gleichen Daten gibt es mir völlig anderes Ergebnis: vgk6yxCrQ5iLFvHxMtQO7w ==

Ich habe auch versucht, AES-256-CBC mit 32-Symbol-Länge iv. In Linux verwende ich aes-256-cbc und in Android verwende ich die Spongy Castle Bibliothek für diesen Zweck, aber es gibt auch andere Ergebnisse.

Was habe ich falsch gemacht? Oder vielleicht haben Sie einen Vorschlag, einen anderen plattformübergreifenden Algorithmus für die Verschlüsselung zu wählen.

+1

Da AES eine gut definierte und gut bekannten Standard, der Algorithmus ist eigentlich das gleiche. Das Problem ist, ich bin sicher, die Eingaben. Sind die tatsächlichen Bytes für die verschiedenen Eingänge (Schlüssel, iv, Daten) alle gleich? Beachten Sie, dass Bytes und Zeichen nicht identisch sind. Der Zeichensatz oder die Codierung ist die Beziehung zwischen ihnen. Stellen Sie außerdem sicher, dass Sie für beide die gleiche Auffüllung verwenden. – dsh

+1

[Java AES 128 verschlüsselt anders als openssl] (http://stackoverflow.com/q/21086103/608639), [Java entspricht einer OpenSSL AES CBC-Verschlüsselung] (http://stackoverflow.com/q/32508961/608639), [Wie dekodiere ich eine mit openssl aes-128-cbc codierte Zeichenkette mit Java?] (Http://stackoverflow.com/q/31947256/608639), [Mit Java entschlüsseln Sie openssl aes-256-cbc mit dem angegebenen Schlüssel und iv] (http://stackoverflow.com/q/15594518/608639), usw. – jww

Antwort

2

Die Parameter -K und -iv erwarten Hex-codierte Strings. Ihr Schlüssel ist 32 Zeichen lang, also 16 Byte oder 128 Bit. Ihre IV ist 16 Zeichen lang, also sind es 8 Byte oder 64 Bit. Eine IV für AES/CBC muss genau 128 Bit lang sein. Wenn nicht, muss es irgendwie gepolstert werden. Ihre IV wird höchstwahrscheinlich mit 0x00 Bytes aufgefüllt, um 128 Bits zu erhalten. Sie müssten das gleiche in Java tun.

Das andere Problem ist, dass Sie den Hex-codierten Schlüssel und IV als Text behandeln, was bedeutet, dass Sie es als einen 256-Bit-Schlüssel und 128-Bit-IV in Java behandeln. Das ist wahrscheinlich nicht das, was du willst. Sie müssen die Zeichenfolgen vor der Verwendung aus Hexen dekodieren.

ist eine imaginäre Implementierung von byte[] fromHex(String hexStr) verwenden lassen:

byte[] ivBytes = new byte[16]; 
byte[] ivBytesShort = fromHex(initVector); 
System.arraycopy(ivBytesShort, 0, ivBytes, 0, ivBytesShort.length); 
IvParameterSpec iv = new IvParameterSpec(ivBytes); 
SecretKeySpec skeySpec = new SecretKeySpec(fromHex(key), "AES"); 
+0

Ja, meine anfängliche iv war 32 Zeichen lang, aber es gab mir Fehler über die Länge von iv, und jetzt verstehe ich warum. Ja, fromHex() funktioniert und es gibt korrekte Ergebnisse. Vielen Dank! –

Verwandte Themen