Random access-Verschlüsselung mit AES in Counter-Modus mit Fortuna PRNG:

Question

Ich baue Datei-Verschlüsselung auf AES basiert, die in Random-Access-Modus (accesing jeden Teil der Datei) in der Lage sein zu arbeiten. AES in Counter kann zum Beispiel verwendet werden, aber es ist bekannt, dass wir eine einzigartige Sequenz nie zweimal verwendet benötigen. Ist es in Ordnung, eine vereinfachtes Fortuna PRNG in diesem Fall zu verwenden (einen Zähler mit einem zufällig gewählten eindeutigen Schlüsseln spezifisch für die jeweilige Datei verschlüsselt)? Gibt es Schwachstellen in diesem Ansatz?

So Verschlüsselung / Entschlüsselung kann so aussehen

Verschlüsselung eines Blocks bei Offset:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)

Decryption eines Blocks bei Offset:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq

Eine Beobachtung. Ich kam auf die Idee, in Fortuna von mir verwendet, und sicherlich später entdeckt, dass es bereits erfunden ist. Aber wie ich überall den Schlüssel Punkt lese darüber Sicherheit, aber es ist ein weiterer guter Punkt: es ist ein großer Schreib-Lese-Pseudo-Zufallszahlen-Generator sozusagen (in vereinfachter Form). So ist die PRNG, die nicht nur sehr gute Folge erzeugt (Getestet habe ich es mit HNO- und Die Hard), sondern auch jede Unterfolge für den Zugriff erlauben, wenn Sie die Schrittnummer kennen. So ist es in der Regel in Ordnung Fortuna als "Random-Access" PRNG in Sicherheitsanwendungen zu benutzen?

EDIT:

Mit anderen Worten, was ich vorschlagen, ist Fortuna PRNG als zwicken zu verwenden, um ein tweakable AES Cipher mit Schreib-Lese-Fähigkeit zu bilden. Ich las die Arbeit von Liskov, Rivest und Wagner, kann aber nicht verstehen, was der wesentliche Unterschied zwischen einer Chiffre in einer Betriebsart war und eine tweakable Chiffre. Sie sagten, sie diesen Ansatz von hohem Niveau in der Chiffre zu bringen vorgeschlagen selbst, sondern zum Beispiel in meinem Fall XOR-Verknüpfung der Klartext mit dem zwicken, dann ist dies ein zwicken oder nicht?

Answer 1

Ich glaube, Sie möchten, wie „tweakable Blockchiffren“ Arbeit sehen und haben einen Blick darauf, wie das Problem der Plattenverschlüsselung ist gelöst: Datenträgerverschlüsselung Theorie . die gesamte Festplatte verschlüsseln ähnelt Ihr Problem: Verschlüsselung jeden Sektor muß unabhängig durchgeführt werden (Sie unabhängige Verschlüsselung von Daten bei verschiedenen Offsets wollen) und doch die ganze Sache muss sicher sein. Es gibt eine Menge Arbeit auf das getan. Wikipedia scheint einen guten Überblick zu geben.

Edited hinzufügen: Re Ihre edit: Ja, versuchen Sie durch XOR-Verknüpfung der zwicken mit dem unverschlüsselten Text eine tweakable Blockchiffre aus AES zu machen. Konkreter Sie Enc (T, K, M) = AES (K, f (T) xor M), wo AES (K, ...) bedeutet AES-Verschlüsselung mit dem Schlüssel K und f (T) ist eine Funktion von die zwicken (in Ihrem Fall, dass ich denke, es ist Fortuna). Ich hatte einen kurzen Blick auf dem Papier Sie erwähnt und soweit ich es sehen kann nachgewiesen werden, dass diese Methode funktioniert nicht erzeugt eine sichere tweakable Blockchiffre. Die Idee (basierend auf Definitionen aus dem Abschnitt 2 des Liskov, Rivest, Wagner Papier) ist wie folgt. Wir haben Zugriff auf entweder die Verschlüsselung Orakel oder eine zufällige Permutation und wir wollen sagen, welche wir mit interagieren. Wir können die zwicken T gesetzt und den Klartext M und wir erhalten die entsprechenden verschlüsselten Text zurück, aber wir wissen nicht, den Schlüssel, der verwendet wird. Hier ist, wie wenn wir den Bau AES (K, f (T) xor M) verwenden, um herauszufinden. Egal auf welche zwei verschiedenen Werte T, T 'compute f (T), f (T'). Pick jede Nachricht M berechnet und dann die zweite Nachricht als M '= M xor F (T) xor F (T'). Jetzt fragen Sie das Verschlüsselungs- Orakel M verschlüsseln mit zwicken T und M ‚mit zwicken T‘. Wenn wir mit dem betrachteten Bau betreffen, werden die Ausgänge identisch sein. Wenn wir mit zufälligen Permutationen betreffen, werden die Ausgänge an Sicherheit grenzender Wahrscheinlichkeit sein (mit einer Wahrscheinlichkeit von 1-2 ^ -128) anders. Das liegt daran, dass beide Eingänge zu den AES-Verschlüsselungen werden die gleichen sein, so dass die Geheimtexte werden ebenfalls identisch. Dies wäre nicht der Fall sein, wenn wir zufällig Permutationen verwendet werden, da die Wahrscheinlichkeit, dass die beiden Ausgänge identisch sind, ist 2 ^ -128. Unterm Strich ist, dass ein XOR-Verknüpfung zwicken mit dem Eingang ist wahrscheinlich keine sichere Methode.

Das Papier gibt einige Beispiele von dem, was sie nachweisen können, eine sichere Konstruktion. Die einfachste scheint Enc (T, K, M) = AES (K, T xor AES (K, M)) zu sein. Sie benötigen zwei Verschlüsselungen pro Block, aber sie beweisen die Sicherheit dieser Konstruktion. Sie erwähnen auch schnellere Varianten, aber sie erfordern zusätzliche primitive (fast-xor-Universal-Funktion Familien).

Answer 2

Auch wenn ich glaube, Ihr Ansatz sicher genug ist, ich sehe keine Vorteile gegenüber CTR. Sie haben genau das gleiche Problem, das Sie nicht echte Zufälligkeit zu dem verschlüsselten Text injizieren tun ist. Der Offset ist ein bekannter systematischer Eingang. Auch wenn es mit einem Schlüssel verschlüsselt ist, ist es noch nicht zufällig.

Ein weiteres Problem ist, wie halten Sie die FileUniqueKey sicher? Verschlüsselte mit Passwort? Eine ganze Reihe Probleme eingeführt werden, wenn Sie mehrere Schlüssel verwendet werden.

Counter-Modus wird die Praxis akzeptiert Random Access-Dateien zu verschlüsseln. Auch wenn es alle Arten von Schwachstellen hat, es ist alles gut untersucht, so das Risiko messbar ist.