2017-11-02 2 views
0

Ich habe ein Token und ein Geheimnis, das benötigt wird, um das Token zu entschlüsseln. Ich bin mir nicht sicher, was ich falsch mache, dass ich "illegale Schlüsselgröße" bekomme. Meine Schlüsselgröße ist 44 Bytes. Ich füge BouncyCastleProvider in einem statischen Block hinzu. Unten ist ein kleiner Ausschnitt dessen, was ich versuche zu tun.Entschlüsseln DES/CBC/ZeroBytePadding Daten

SecretKeySpec skeySpec = new SecretKeySpec(keyText.getBytes(), "DES"); 
Cipher des = Cipher.getInstance("DES/CBC/ZeroBytePadding", "BC"); 
des.init(Cipher.DECRYPT_MODE, skeySpec, new IvParameterSpec(new byte[8])); 
byte[] tokenData = des.doFinal(Base64.decodeBase64(token)); 

Antwort

1

Meine Vermutung ist, dass Ihr keyText Base64 codiert ist. Sie sollten es wahrscheinlich dekodieren, um ein Byte [] von 32 Bytes zu erhalten. In Java 8 können Sie so etwas tun:

byte[] key = java.util.Base64.getDecoder().decode(keyText.getBytes()); 
SecretKeySpec skeySpec = new SecretKeySpec(key, "DES"); 
Cipher des = Cipher.getInstance("DES/CBC/ZeroBytePadding", "BC"); 
des.init(Cipher.DECRYPT_MODE, skeySpec, new IvParameterSpec(new byte[8])); 
byte[] tokenData = des.doFinal(Base64.decodeBase64(token)); 

Diese andere Frage enthält weitere Informationen zu Base64. Converting Secret Key into a String and Vice Versa

Ich denke immer noch, dass Sie ungültige Schlüsselgrößenfehler erhalten werden. Ist kein DES-Schlüssel 56 Bits (plus 8 Paritätsbits)? Das wäre also nur 8 Bytes lang, nicht 44 oder die 32, die ich denke, wenn Sie Base64 dekodieren.

+0

Ja, DES verwendet einen 8-Byte-Schlüssel. – zaph

+0

Ich dekodiere es bereits in doFinal. – Bytekoder

3

DES hat eine Schlüsselgröße von 56 Bits in 8 Bytes, der LSB jedes Bytes ist für die Parität reserviert, wird aber normalerweise ignoriert.

So "Meine Schlüsselgröße ist 44 Bytes" ist falsch.

Als nächstes ist die IV für die Entschlüsselung verwendet werden müssen die gleichen wie für die Verschlüsselung verwendet wurde. DES hat eine Blockgröße von 8 Bytes, also muss die IV 8 Bytes haben. Eine allgemeine Art, die IV zu handhaben, besteht darin, die verschlüsselten Daten damit voranzutreiben, die IV muss nicht geheim sein.

Schließlich ist Zero Padding im Allgemeinen keine gute Lösung, es unterstützt keine Binärdaten, die mit einem Nullbyte enden können. PKCS # 5 ist das allgemein verwendete Padding.

+0

Null Padding ist in den meisten Fällen eine schlechte Idee, aber (nicht-dreifach) DES ist immer eine viel schlimmere. –

+0

Am besten, um 3DES direkt zu AES zu überspringen, ist es der aktuelle Standard. – zaph

+0

Ich stimme Ihrem Kommentar zu Null-Padding zu, aber wir haben nur ein Legacy-System und müssen noch ein paar Tage damit leben. Das Problem war also sowohl der Schlüssel als auch die verschlüsselten Daten. – Bytekoder

Verwandte Themen