Warum muss ich die Rfc2898DeriveBytes-Klasse (in .NET) verwenden, anstatt das Kennwort direkt als Schlüssel oder IV zu verwenden?

Question

Was ist der Unterschied zwischen der Verwendung von Rfc2898DeriveBytes und der Verwendung von Encoding.ASCII.GetBytes(string object);?

Ich hatte relativen Erfolg mit beiden Ansatz, der erste ist ein langatmiger Ansatz, wo wie der letztere ist einfach und auf den Punkt. Beide scheinen es Ihnen zu ermöglichen, das Gleiche zu tun, aber ich kämpfe, um den Punkt zu erkennen, indem ich Ersteres über letzteres verwende. Das Grundkonzept, das ich verstehen konnte, ist, dass Sie String-Passwörter in Byte-Arrays konvertieren können, die beispielsweise für eine symmetrische Verschlüsselungsklasse AesManaged verwendet werden. Über die RFC-Klasse können Sie beim Erstellen Ihres RFC-Objekts jedoch die salt-Werte und das Passwort verwenden. Ich nehme an, es ist sicherer, aber das ist immer noch eine ungebildete Vermutung! Außerdem können Sie damit Byte-Arrays einer bestimmten Größe zurückgeben.

Hier sind ein paar Beispiele, die Sie zu zeigen, wo ich komme: jetzt

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password"); 

oder

string password = "P@%5w0r]>"; 
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt"); 
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray); 

Die ‚rfcKey‘ Objekt kann die die .KEY in Richtung der Einrichtung verwendet werden oder .IV Eigenschaften auf einer symmetrischen Verschlüsselungsalgorithmusklasse.

dh.

'rj' sollte bereit sein zu gehen!

Der verwirrende Teil ... also kann ich nicht einfach das 'rfcKey'-Objekt verwenden, kann ich nicht einfach mein ' myPassInBytes'-Array verwenden, um mein 'rj'-Objekt einzurichten?

Ich habe versucht, dies in VS2008 und die sofortige Antwort ist nein. Aber haben Sie eine besser ausgebildete Antwort, warum die RFC-Klasse gegenüber der anderen Alternative, die ich oben erwähnt habe, verwendet wird?

Answer 1

Sie wollen wirklich, ein Benutzerpasswort nicht direkt als Kryptoschlüssel verwenden, insbesondere mit AES.

Rfc2898DeriveBytes ist eine Implementierung von PBKDF2. Was es tut, ist wiederholt Hash-das Benutzer-Passwort zusammen mit dem Salz. Dies hat mehrere Vorteile:

Erstens können Sie beliebig große Passwörter verwenden - AES unterstützt nur bestimmte Schlüsselgrößen.

Zweitens bedeutet das Hinzufügen des Salzes, dass Sie die gleiche Passphrase verwenden können, um mehrere verschiedene Schlüssel zu generieren (vorausgesetzt, das Salz ist keine Konstante, wie in Ihrem Beispiel). Dies ist wichtig für die Schlüsseltrennung. die Wiederverwendung von Schlüsseln in verschiedenen Kontexten ist eine der häufigsten Arten, wie kryptographische Systeme durchbrochen werden.

Die mehreren Iterationen (standardmäßig 1000) verlangsamen das Erraten von Kennwörtern. Betrachten Sie jemanden, der versucht, Ihren AES-Schlüssel zu erraten. Wenn Sie nur das Passwort verwendet haben, wäre dies einfach - versuchen Sie einfach jedes mögliche Passwort als Schlüssel. Auf der anderen Seite muss der Angreifer mit PBKDF2 zuerst 1000 Hash-Iterationen für jede Passwort erraten. Während es einen Benutzer nur geringfügig verlangsamt, wirkt es sich überproportional auf einen Angreifer aus. (In der Tat ist es üblich, viel höhere Iterationszahlen zu verwenden; 10000 wird häufig empfohlen).

Es bedeutet auch, dass der endgültige Ausgabeschlüssel gleichmäßig verteilt ist. Wenn Sie zum Beispiel das Passwort verwendet haben, wären typischerweise 16 von 128 Bits des Schlüssels 0 (das hohe ASCII-Bit). Das macht die Suche nach keysearch 65536-mal so einfach wie es sein sollte, selbst wenn man das Erraten des Passworts ignoriert.

Schließlich hat AES spezifische Sicherheitslücken mit verwandten Schlüsselangriffen. Verwandte Schlüsselangriffe sind möglich, wenn ein Angreifer einige Daten kennt, die mit mehreren Schlüsseln verschlüsselt wurden, und es gibt eine bekannte (oder erratene) Beziehung zwischen ihnen. Wenn Sie beispielsweise Daten mit einem Passwort-Schlüssel "Mein AES-Schlüssel saugt" (16 Bytes, für AES-128) und mit "MEIN AES-SCHLÜSSEL SAUGEN" verschlüsselt haben, ist möglicherweise ein damit zusammenhängender Schlüsselangriff möglich. Die derzeit bekanntesten Angriffe erlauben zwar nicht, die gesamte AES auf diese Weise zu durchbrechen, aber sie wurden mit der Zeit immer besser - erst letzte Woche wurde ein neuer Angriff veröffentlicht, der 13 Runden (von insgesamt 14) von AES-256 mit bricht ein damit zusammenhängender Schlüsselangriff. Es wäre zutiefst unklug, sich darauf zu verlassen, dass solche Angriffe im Laufe der Zeit nicht besser werden.

Answer 2

Kurze Antwort: Es ist sicherer. Aus dem gleichen Grund gibt es auch einen speziellen Zufallsgenerator im System.Security-Namespace.

Weitere Informationen finden Sie RFC2898

ich ein wenig Teil verstehen:

mit Encoding.ASCII.GetBytes(), wenn Sie ein langes Passwort verwenden, werden Sie höchstens die ersten rj.KeySize Bytes verwenden davon. Der Rest wird ignoriert. Und wenn Ihr Passwort kürzer als die Schlüsselgröße ist, müssen Sie Padding hinzufügen (und nur eine Folge von Nullen hinzufügen, um die Sicherheitslücke zu erhöhen).