Gemäß DES-Spezifikation wird das letzte Bit jedes Bytes des geheimen Schlüssels zur Fehlererkennung verwendet (jedes Byte sollte eine ungerade Parität haben). Daher ist die effektive Schlüssellänge 56 Bits, nicht 64 Bits.Behält DESKey ungültige Paritätsbits?
In vielen Anwendungsfällen werden diese Paritätsbits jedoch nicht überprüft. Manchmal werden sie sogar für einen ganz anderen Zweck verwendet: Mifare DESFire-Karten speichern beispielsweise die Schlüsselversion in diesen Bits, obwohl der ursprüngliche Zweck der Fehlerkorrektur verloren geht.
Wie behandeln Java Card-Implementierungen diese Bits? Lassen Sie uns an diesem Code einen Blick:
DESKey desKey = ... //a single DES key instance
byte[] inputKey = new byte[8];
inputKey[7] = (byte) 0x03; //explicitly invalid parity bit in the last byte
desKey.setKey(inputKey, (short) 0);
byte[] outputKey = new byte[8];
desKey.getKey(outputKey, (short) 0);
ist sichergestellt, dass inputKey
und outputKey
Arrays die gleichen Daten am Ende enthalten, auch mit ungültigen Paritätsbits im inputKey
? Ich habe mehrere Experimente mit ein paar Kartentypen durchgeführt und sie behalten alle Daten, die ich in diese Paritätsbits geschrieben habe, aber ich habe in der Java Card-Spezifikation keine Erwähnung gefunden, dass dieses Verhalten garantiert ist.
Diese Information ist sehr wichtig für mich; andernfalls müsste ich meine "ungültigen Paritätsbits" getrennt von der Schlüsselinstanz speichern.
Ich hatte genau das gleiche Dilemma und beschloss, die Schlüsselversion in einem separaten Feld zu speichern, nur um sicher zu gehen. Ich konnte auch keine Garantien in den Spezifikationen finden - meine Wette ist, dass es undefiniert ist, also gefährlich. Meine Karten hielten die Paritätsbits auch intakt ... Viel Glück! – vlp