2012-03-30 9 views
3

Ich habe ein Paar AES verschlüsseln/entschlüsseln Funktionen basierend auf dieser example geschrieben.Validieren Sie Schlüssel/IV, bevor Sie mit AesManaged entschlüsseln? oder vermeiden Sie CryptographicException, bevor es auftritt?

Es funktioniert gut, bis ich den falschen Schlüssel oder IV in meine Entschlüsselungsfunktion übergeben, an diesem Punkt bekomme ich die "Padding ist ungültig und kann nicht entfernt werden." CryptographicException, die andere besprochen haben.

Meine Frage ist: Gibt es eine Art, den Schlüssel/IV zu validieren, bevor die Ausnahme auftritt? Vielleicht eine Art Prüfsumme? Oder ist die Antwort nur diese Ausnahme zu fangen?

+0

Hinweis: Wenn Sie eine gute Möglichkeit zum Speichern von Benutzerkennwörtern suchen, verwenden Sie keine Verschlüsselungsfunktion wie AES. Sie möchten eine Einweg-Hash-Funktion wie [bcrypt] (http://codahale.com/how-to-safely-store-a-password/) .... [mehr Infos] (http: //security.stackexchange .com/questions/4781/do-any-security-experts-empfehlen-bcrypt-for-password-storage/4784 # 4784) –

Antwort

1

Die Antwort ist nur, um die Ausnahme ja zu fangen. Die IV wird normalerweise mit der verschlüsselten Nachricht gesendet, daher ist es wenig sinnvoll, diese separat zu validieren. Wie für den Schlüssel, den Schlüsselwert wird mit einem KCV (key Prüfwert) die normale Art und Weise zu überprüfen:

überprüfen Sie den asnwer von Poncho über meine Frage hier:

https://crypto.stackexchange.com/questions/1930/sending-kcv-key-check-value-with-cipher-text

Im Grunde ist es tut scheint es nicht wert zu sein. Ihre Kilometerzahl kann natürlich variieren. Das Hinzufügen einer Art von Authentifizierung zu Ihrer verschlüsselten Nachricht ist jedoch immer sehr sinnvoll, aber es zeigt Ihnen immer noch nicht, ob die Daten beschädigt oder manipuliert sind oder ob Sie den falschen Schlüssel haben ...

+0

In dem Beispiel akzeptiert Encrypt() ein Salz, das an die PBKDF2-Funktion übergeben wird. Zufällige Salze sollten zufällige IV erzeugen, oder? –

+0

Solange Sie PasswordDeriveBytes (ein schlecht definiertes, schlecht programmiertes PBKDF1) verwenden, kann leider grundsätzlich alles passieren. Wenn Sie zu [Rfc2898DeriveBytes] wechseln würden (http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx) post haste (wollte immer diesen Begriff verwenden, sorry). Aber wenn Sie das tun und das Salz nicht wiederverwenden, sollten Sie in Ordnung sein. Dennoch sollte eine vollständig zufällige IV bevorzugt werden. –

+0

Gelöschter vorheriger Kommentar, weil ich die PasswordDeriveBytes übersehen habe, was der veraltete PBKDF1-Algorithmus oder zumindest eine Bastard-Version davon ist. –

0

Die einzige Sache, die mit verschlüsselten Daten ungültig sein kann, ist, dass sie eine falsche Länge haben könnte (nur durch das Fachprinzip). Einige Auffüllschemata erfordern, dass die Daten eine Größe haben, die ein Vielfaches der Blockgröße ist. Andere Padding-Schemata haben keine solche Einschränkung.

+0

Hmm, beide Sätze scheinen falsch zu sein, wenn Sie mich fragen, und ich sehe nicht wie Sie beantworten die Frage. –

+0

Ich versuche einen Weg zu finden, um festzustellen, ob die Daten die falsche Größe haben (das ist was die Ausnahme eigentlich bedeutet! * Any * IV und Key der richtigen Größe ist gültig. Also ist * any * Daten. Es gibt keine Ding als ungültiger Chiffretext). – usr

+0

Nein, die Ausnahme bedeutet, dass die Füllbytes falsche Werte haben, was nicht bedeutet, dass die Daten die falsche Größe haben (welche Daten, der Klartext oder der Chiffretext?). Es ist ein ungültiger Chiffretext vorhanden: Die Ausgabe der ECB- oder CBC-Modus-Verschlüsselung ermöglicht nur N * Blocksize-Chiffretexte. Schließlich scheint Ihr letzter Satz über Block-Modus-Chiffren gegen Strom-Chiffren zu sein, Füll-Schemata werden explizit verwendet, um Klartext zu erzeugen, der mit dem Block-Modus kompatibel ist. –

Verwandte Themen