2013-05-27 10 views
5

Meine Abteilung bei der Arbeit wird von den Kräften benötigt, eine Verschlüsselungsbibliothek zu verwenden, die von einer anderen Abteilung geschrieben wurde. Das Problem ist, dass die Verschlüsselungsbibliothek ihr AES fest codiert hat Zählermodus-Initialisierungsvektor (Nur-Nullen). (Im Grunde nahm die andere Abteilung die Bouncycastle-Bibliothek und wickelte ihren eigenen kaputten Code darum herum.) Wir haben die Probleme mit diesem Code für die Befugnisse dokumentiert, so dass wir, wenn das Management nicht beschließt, eine kaputte Verschlüsselungsbibliothek verwenden .AES Counter-Modus - Verschlüsselungsbibliothek hat seinen Initialisierungsvektor fest codiert

Ich frage mich, ob wir einen richtigen Initialisierungsvektor vortäuschen könnten, indem wir eine eindeutige IV dem Klartext voranstellen und dann die ersten sechzehn Bytes Klartext nach der Entschlüsselung abschneiden, z.

ciphertext = encrypt(++sixteenByteCounter + plaintext) 
plaintext = decrypt(ciphertext).subArray(16, ciphertext.length) 

Das scheint mir gut, aber ich bin kaum ein Kryptographie-Experte

+0

Nein, nichts abzuschneiden wird nichts nützen :). IV wird für Verkettungsmodi verwendet und nimmt an der Verschlüsselung teil. –

+0

@ EugeneMayevski'EldoSCorp Eine IV wird üblicherweise auch als Anfangswert für die Nonce-Verschlüsselung im Zählermodus verwendet. Und ich denke, es ging darum, mehr Sicherheit zu bekommen, indem man einen Wert vorlegt und den entschlüsselten Klartext nicht abschneidet. –

+0

Es wird dir nichts nützen. Das oberste 96-Bit des Zählers MUSS für jede Nachricht eindeutig sein, andernfalls wird ein einfacher Xor zwischen Nachrichten Ihre Daten gefährden. Hinzufügen von Junk zu verschlüsselt werden hier nicht helfen. Die Implementierung muss geändert werden. –

Antwort

5

Noooooo ....

In CTR-Modus können Sie eine Folge von Zahlen verschlüsseln (1,2,3 ...) und dann deine Nachricht dagegen zu XORIEREN.

Es ist notorisch einfache Verschlüsselung zu knacken, dass XORs Werte gegen eine wiederverwendet Sequenz. Um dies im CTR-Modus zu vermeiden, starten Sie jedes Mal mit einem zufälligen Offset (Sie beginnen nicht bei 1, sondern beispielsweise bei 75437454896785). Das ist die "IV" im CTR-Modus. Es ist nicht wie eine IV in der Kette. Es ist ein numerischer Offset zu dem, wo Sie anfangen zu zählen.

Siehe https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29 - die IV ist die "Nonce" (die höheren Bits im Zähler).

Was Sie vorschlagen, scheint auf dem CBC-Modus oder ähnlichem zu basieren, wo die IV verwendet wird, um den nächsten Block zu mähen, der wiederum verwendet wird, um den nächsten Block zu mähen und so weiter. Aber das ist völlig unabhängig davon, wie IV im CTR-Modus verwendet wird.

Ihr Fix würde den Startpunkt der verwendeten Nummern nicht ändern, und Ihre Nachrichten wären hoffnungslos unsicher. Bitte tu das nicht.

Außerdem gibt es eine Kryptoäquivalent zu Stackoverflow, wo Sie wirklich solche Dinge fragen sollten. https://crypto.stackexchange.com/

ABER WARTEN. Jetzt denke ich darüber nach ... Ich kenne die betreffende API nicht. Es kann sein, dass die IV einfach nicht verwendet wird (vielleicht wird die IV in der API nur für die Art der Verkettung verwendet, die in CBC durchgeführt wird). Wie breit ist der Zähler? Könnte es sein, dass die API erwartet, dass Sie den Zähler mit einem zufälligen Offset starten? Ich denke nicht, aber Sie müssen wirklich die Dokumente/den Code lesen, um sicher zu sein (ich weiß, dass ich bei diesem Problem mit PyCrypto gebissen wurde).

Aber wie auch immer, Ihre Lösung ist sicherlich keine Lösung (leider).

Verwandte Themen