it-swarm.com.de

Fügt die Wahl des Verschlüsselungsalgorithmus nicht selbst Entropie hinzu?

Angenommen, jemand hat meine verschlüsselten Daten und möchte sie entschlüsseln. Die Leute reden immer darüber, wie die Länge des Schlüssels (z. B. 256 Bit) über die Entropie der Verschlüsselung entscheidet, was absolut sinnvoll ist. Wenn der Angreifer alle 2 versucht256 Möglichkeiten, seine Ur-Ur-Ur-Kinder werden meine Daten haben.

Aber was ist, wenn er all die Jahre den falschen Algorithmus verwendet hat? Fügt die Wahl des Algorithmus selbst nicht auch Entropie hinzu, oder bin ich falsch, dies anzunehmen? Also anstatt meine Datei zu benennen super_secret.aes256 Ich würde es einfach nennen super_secret.rsa256 oder vielleicht gar keine Datei enden lassen?

50
Robert

Wenn Sie ein Kryptosystem entwerfen, lautet die Antwort Nein . Kerckhoffs Prinzip besagt: "Ein Kryptosystem sollte sicher sein, auch wenn alles am System außer dem Schlüssel öffentlich bekannt ist." Angepasst an Shannons Maxime bedeutet dies: "Man sollte Systeme unter der Annahme entwerfen, dass der Feind sofort mit ihnen vertraut wird."

Die Annahme, dass der Angreifer Ihren Algorithmus nicht lernt, ist Sicherheit durch Dunkelheit , ein Sicherheitsansatz, der als unzureichend angesehen wird.

Wenn Sie sich darauf verlassen, dass der Angreifer den Algorithmus nicht kennt, wird dies keine Arbeit für ihn bedeuten, da er oder sie es laut Kerckhoff entweder weiß oder vernünftigerweise erwartet werden kann, dass er es herausfindet. Wenn es keine Unsicherheit hinzufügt, fügt es keine Entropie hinzu. Und ihre Fähigkeiten können Sie nicht quantifizieren.

Im Falle eines verlorenen Kryptosystems, wie Sie es beschreiben, gibt es normalerweise genügend historische oder statistische Informationen, um die Art des Algorithmus zu bestimmen (wenn nicht den Schlüssel selbst). Sie können jedoch kein System unter der Annahme entwerfen, dass dies der Fall ist verloren, sobald es verwendet wird. Das ist OpSec, keine Kryptographie.

[~ # ~] edit [~ # ~] In Kommentaren wurde die Verwendung der Algorithmusauswahl als Teil des Schlüssels erwähnt. Das Problem bei diesem Ansatz besteht darin, dass die Algorithmusauswahl notwendigerweise vor der Entschlüsselung der Daten bestimmt werden muss. Genau so funktionieren Protokolle wie TLS heute.

Wenn Sie wirklich versuchen, Algorithmen miteinander zu mischen und einen Schlüsselfaktor zu verwenden, um Dinge wie die S-Box-Auswahl usw. zu bestimmen, erstellen Sie effektiv einen einzigartigen neuen Algorithmus (der alle bekannten Risiken übernimmt, die mit dem Rollen Ihrer eigenen verbunden sind Algorithmus beinhaltet.) Und wenn Sie einen neuen Algorithmus erstellt haben, sind alle Bits des Schlüssels Teil dieser Entropieberechnung. Wenn Sie jedoch auf bestimmte Bits hinweisen können, die den Algorithmus anstelle von Schlüsselmaterial bestimmen, müssen Sie sie dennoch als Protokollbits behandeln und ausschließen.

In Bezug auf die Geheimhaltung der Algorithmen mag Ihr Protokoll heute geheim sein, aber wenn einer Ihrer Agenten entdeckt und sein System kopiert wird, verwenden die alten Nachrichten keine geheimen Algorithmen mehr, selbst wenn keine Schlüssel kompromittiert werden. Jede „Entropie“, die Sie ihnen zugeschrieben haben, geht verloren, und Sie wissen es möglicherweise nicht einmal.

93
John Deters

In der Praxis nein, wie Johns Antwort ordentlich erklärt.

Wenn Sie hypothetisch genug sichere Verschlüsselungsmethoden zur Auswahl hätten, könnten Sie möglicherweise eine Methode nach dem Zufallsprinzip auswählen und damit beispielsweise die Daten verschlüsseln - Ein 256-Bit-Schlüssel. Die Wahl des verwendeten Algorithmus müsste dem Schlüssel "hinzugefügt" werden und Teil des " nicht offenbarten Geheimnisses " werden (unter Verwendung der kombinierten Entropie) auf 259 Bit, wenn acht Verschlüsselungsalgorithmen zur Auswahl standen).

Die Probleme dabei sind:

  • Es wird nur eine kleine Anzahl von Bits hinzugefügt: Acht Algorithmen fügen nur drei Entropiebits hinzu. Das Hinzufügen von acht Bits (für insgesamt 264 Bits mit einem 256-Bit-Schlüssel) würde 256 verschiedene Verschlüsselungsalgorithmen erfordern. Es ist mit ziemlicher Sicherheit viel schwieriger, genügend sichere Algorithmen zu finden, um einen praktischen Unterschied zu bewirken, als nur die Schlüssellänge eines einzelnen Angreifers zu verlängern, der dem Angreifer bekannt ist , Algorithmus.

  • Sie müssen den Schlüssel mit der Wahl des Algorithmus "erweitern": Dies bedeutet, dass die Wahl an den "Benutzer" übergeben wird, um sich neben dem normalen Schlüssel "zu erinnern". Dies erschwert den Prozess der Schlüsselverwaltung erheblich. Das Speichern der Auswahl in den verschlüsselten Daten ist ein Nichtstarter, da ein Angreifer mit "Gesamtwissen" in der Lage wäre, die Informationen zu finden und zu wissen, welcher Algorithmus verwendet werden soll.

  • Wenn einer der ausgewählten Algorithmen einen "Fingerabdruck" hinterlässt, der es einem Angreifer ermöglicht, den verwendeten Algorithmus zu identifizieren (oder zumindest den Bereich möglicher Algorithmen zu verringern), werden dadurch die zusätzlichen Entropiebits (teilweise) aufgehoben.

Alles in allem ist es viel einfacher, die Länge des verwendeten Schlüssels zu verlängern, ohne sich Sorgen zu machen, dass ein Angreifer die Verschlüsselungsmethode kennt.

47
TripeHound

Die Antworten von @John Deter und @TripeHound erklären die Dinge sehr gut, aber ich wollte ein Beispiel geben, das Kerckhoffs Prinzip in einen Kontext stellt. Es ist natürlich, diese Fragen aus der Perspektive eines externen Angreifers zu betrachten, aber dies ist nicht das einzige relevante Bedrohungsmodell. Tatsächlich geht ungefähr die Hälfte aller Datenverletzungen von internen Agenten (auch bekannt als Mitarbeiter, Auftragnehmer usw.) aus, mit einer Mischung aus zufälligen und absichtlichen Lecks.

Realistischere Bedrohungsvektoren

Ein versteckter Verschlüsselungsalgorithmus kann gegen einen externen Angreifer hilfreich sein, wenn dieser nicht leicht ableiten kann, welches System Sie verwendet haben. Es bietet jedoch absolut keinen zusätzlichen Schutz gegen einen Insider, der Zugriff auf Ihren Code hat. Wenn Ihr System als extremes Beispiel wichtige personenbezogene Daten (PII) in Ihrer Datenbank speichert, aber sowohl Zugriffsdaten für die Produktionsdatenbank als auch Verschlüsselungsalgorithmen und Verschlüsselungsschlüssel direkt in Ihrem Code-Repository gespeichert sind, haben Sie effektiv jedem Zugriff gewährt Zugriff auf alle PII Ihrer Kunden auf Ihr Code-Repository.

Natürlich möchten Sie das nicht tun, also halten Sie Produktionssysteme von allen erwarteten Administratoren getrennt. Sie halten Verschlüsselungsschlüssel in einem separaten Schlüsselverwaltungssystem gespeichert, auf das (so weit wie möglich) nur die Anwendung usw. zugreifen kann Entwickler wissen, welche Verschlüsselungsalgorithmen verwendet werden (weil sie sie im Code-Repository sehen können), haben jedoch keinen Zugriff auf die Produktionsdatenbank, und selbst wenn sie Lesezugriff auf die Datenbank erhalten würden, hätten sie nicht die Schlüssel dazu entschlüsseln Sie die Daten, die dort sind.

Anwendung des Kerckhoffschen Prinzips

Das ist der springende Punkt von Kerckhoffs Prinzip - das einzige, was Sie geheim halten müssen, ist das eigentliche Geheimnis (auch bekannt als Ihr Verschlüsselungsschlüssel). Alles andere kann jeder kennen und Sie sind immer noch sicher. Was gut ist, weil es schwer genug ist, nur ein Geheimnis zu bewahren. Der Versuch, ein System zu entwickeln, das nicht nur die Schlüssel, sondern auch die Verschlüsselungsalgorithmen und andere Details vor möglichst vielen Personen verbirgt, ist etwas schwieriger und fehleranfälliger.

Kurz gesagt, die Leute sind schlecht darin, Geheimnisse zu bewahren. Wenn Sie Ihr System so gestalten, dass Sie weniger Geheimnisse haben, werden Sie sicherer , auch wenn dies nicht intuitiv zu sein scheint. Schließlich macht das, was Sie vorschlagen, in gewisser Hinsicht Sinn: Warum sollten wir nur unsere Daten verschlüsseln? Lassen Sie uns auch die Verschlüsselungsmethode ausblenden und besonders sicher sein! In der Praxis bietet das Ausblenden von mehr Dingen jedoch mehr Raum für Fehler machen und ein Gefühl falscher Sicherheit. Es ist viel besser, eine effektive Verschlüsselungsmethode zu verwenden, die die Geheimhaltung so einfach wie möglich macht - verstecken Sie den Schlüssel und die Nachricht ist sicher.

11
Conor Mancone

Wenn es abstrakt 2 ^ n Verschlüsselungsschemata gibt, die genau gleich schwer zu brechen sind und denselben Platz für mögliche Schlüssel haben, können Sie ein neues Verschlüsselungsschema als "zufällig eines dieser 2 ^ n Schemata auswählen" und definieren Betrachten Sie effektiv diese n Bits, die dem Schlüssel hinzugefügt werden sollen.

Aber in der Praxis, selbst wenn dies möglich wäre, ist dies eine Menge unnötiger Komplexität, wenn Sie stattdessen einfach einen einzelnen Algorithmus auswählen und den Schlüssel etwas länger machen könnten.

8

Ich denke, OP-Frage zeigt Einsicht und die Antwort ist, zumindest theoretisch, ja. Hier ist etwas. Ich denke, das ist der erste Punkt, der gemacht werden sollte. Die Antworten sind größtenteils der Ansicht: In der Praxis funktioniert das nicht so. Diese sind nicht falsch, aber ich denke, sie vermissen die Gültigkeit/das Interesse des OP-Punktes.

So begründe ich das: Aus theoretischer Sicht ist die Wahl zwischen zwei Verschlüsselungssystemen analog zur Wahl des ersten Bits des Schlüssels. Tatsächlich sind sie wirklich dasselbe (wenn Sie das Bit zurück hinzufügen). In einer Blackbox ist der Schlüssel wirklich nichts Besonderes. Sie sind nur eine gute Möglichkeit, Ihre Optionen für die Verschlüsselungstransformationen aufzulisten, die Sie verwenden möchten.

Um das zu sehen:

Angenommen, ich mache eine neue Variante von AES128, nennen wir sie JES_0_128. Dies funktioniert folgendermaßen: Ich füge der Vorderseite des mitgelieferten Schlüssels eine Binärcodierung von 0 (in diesem Fall 128 Nullen) hinzu und verwende diese in (Standard) AES256. Dann mache ich eine andere mit dem Namen JES_1_128: eine Codierung von 1 usw. bis zu JES_ (was auch immer 2 ^ 128 in Basis 10 ist) _128. All dies sind perfekt gültige 128-Bit-Schlüsselverschlüsselungsalgorithmen. Aber wenn Sie nicht wissen, welches ... es ist ein 256-Bit-Schlüsselverschlüsselungsalgorithmus. AES256 um genau zu sein. Welches ist in der Tat viel mehr Entropie.

Die anderen Antworten weisen darauf hin, dass ein Schlüssel in der Praxis eine sehr gute Möglichkeit ist, den zu verwendenden 2 ^ 256 AES-256-Verschlüsselungsalgorithmus auszuwählen. Es ist flexibel, gut verstanden und überlässt das Generieren und Vertrauen des gegenseitigen Geheimnisses den Benutzern. Warum noch etwas verwenden?

Auf der anderen Seite ist es nicht sehr gut, eine der wenigen 256-Bit-Familien von Verschlüsselungsalgorithmen auszuwählen und fest zu codieren. Auch im Vergleich zu einer sehr geringen Zunahme der Schlüsselgröße. Oder überhaupt. Sie können es auch einfach allen erzählen. Aus praktischer/Schreibsoftware-/Typensicht ist es überhaupt nicht sicher, sich darauf zu verlassen, dass dies von einem Angreifer jeglichen Interesses ferngehalten wird. Es gibt eine Vielzahl von Gründen dafür. Nicht zuletzt, wenn ein Angreifer eine Kopie hätte, welchen Wert Sie ausgewählt haben, wäre es einfach, welchen zu testen. Aber es sind "nur" praktische Überlegungen ...

1
drjpizzle

Ich denke, das ist eine gute Sichtweise:

Sie haben ein Geheimnis, bei dem es sich möglicherweise um einen 256-Bit-Schlüssel handelt, oder ein Kennwort, von dem Sie diesen Schlüssel ableiten, oder eines dieser Kennwörter sowie weitere Informationen wie den von Ihnen verwendeten Verschlüsselungsalgorithmus.

Der Angreifer möchte Ihr Geheimnis erraten. Sie tun dies, indem sie verschiedene Möglichkeiten ausprobieren, bis sie die richtige finden oder ihnen Zeit, Geld oder Motivation ausgehen.

Sie haben keine Ahnung, welche Möglichkeiten sie versuchen . In Ihrer Frage sagen Sie: "Was ist, wenn er all die Jahre den falschen Algorithmus verwendet hat?" und die einzige Antwort darauf ist "Was wäre, wenn er es nicht wäre?" Sie haben keine Kontrolle darüber. Wenn Sie wüssten, welche Möglichkeiten der Angreifer versuchen würde, könnten Sie einfach alles auswählen, was nicht auf seiner Liste steht, und das Sicherheitsproblem wäre trivial gelöst.

Sie können jedoch grob abschätzen, wie viele Möglichkeiten sie ausprobieren können, bevor ihnen Zeit und/oder Geld ausgehen, basierend auf dem Stand der Computertechnologie. Dies setzt voraus, dass sie nicht heimlich Zugang zu Technologie haben, die der Rest der Welt nicht hat, wie zum Beispiel Quantencomputer oder eine Hintertür in AES - was wahrscheinlich eine sichere Annahme ist, da sie in diesem Fall bessere Dinge zu tun hätten als Versuchen Sie, Ihr Passwort zu knacken. (Vgl. Lex Luthor einen Scheck abschneiden , siehe aber auch diese Widerlegung .)

Sie können auch das folgende Ergebnis beweisen : Wenn Sie Ihr Geheimnis gleichmäßig zufällig (unter Verwendung eines hochwertigen RNG) aus auswählen ) n Möglichkeiten, und der Angreifer versucht k Möglichkeiten, egal was sie sind , die Chance, dass sie dein Geheimnis erraten, ist höchstens k / n .

Das Schöne ist, dass n exponentiell mit der Menge an Informationen wächst, die Sie speichern/merken müssen, während k wächst nur linear mit der Menge an Zeit/Geld, die sie ausgeben, daher ist es nicht schwer, k / n sehr klein.

Sie sollten Ihr Geheimnis also einheitlich zufällig aus einer Vielzahl von Möglichkeiten auswählen. Ein zufälliger symmetrischer 256-Bit-Schlüssel wird einheitlich aus einem Satz von Größe 2 ausgewählt256, die (weit mehr als) groß genug ist.

Sie können auch zufällig aus einer Reihe von (Algorithmus-, Schlüssel-) Paaren auswählen, aber es ist sinnlos, da jeder einzelne Algorithmus bereits viele Auswahlmöglichkeiten bietet.

Sie können einen obskuren Algorithmus auswählen und hoffen, dass der Angreifer ihn nicht ausprobiert, aber das wählt nicht mehr zufällig aus, und deshalb können Sie es nicht beweisen , dass es überhaupt hilft. Wenn es keine anderen Optionen gäbe, wäre dies besser als nichts, aber es gibt andere Optionen.

Dies ist der grundlegende Grund, warum Kryptographen Ihnen raten, nur den Schlüssel als Ihr Geheimnis zu behandeln: Es gibt viele Schlüssel, und Schlüssel sind am einfachsten zufällig auszuwählen. Du brauchst nichts anderes.

0
benrg

Wenn Sie nur etwas mit einem Algorithmus verschlüsseln und so tun, als ob ein anderer verwendet wurde, gilt das Kerckhoff-Prinzip wie in anderen Antworten angegeben. Das ist also irgendwie nutzlos, zumindest gegen einen Angreifer mit Kenntnissen über unsere Implementierung. Es wird immer noch gegen einen Angreifer "funktionieren", der z. stiehlt die verschlüsselte Datei von Ihrem OneDrive oder einem anderen Cloud-Speicher, ohne etwas darüber zu wissen.

Wenn die Auswahl des Verschlüsselungsalgorithmus in den Entschlüsselungsprozess einbezogen werden soll (d. H. Ihr Tool wählt je nach Eingabe einen von mehreren Algorithmen aus), fügen Sie Ihrer Schlüssellänge effektiv Bits hinzu. Kerckhoffs Prinzip gilt hier nicht. Es ist jedoch schwierig, eine signifikante Anzahl von Bits hinzuzufügen - man würde viele Algorithmen zur Auswahl benötigen - und es macht keinen Sinn (siehe letzter Absatz).

In jedem Fall ist alles, was Sie tun möchten, ziemlich sinnlos. Die Annahme, dass die Ur-Ur-Enkel-Kinder von jemandem Ihre Daten haben könnten, wenn sie ein paar Milliarden in Geräte und Stromrechnung investieren, trifft wohl auf Schlüssel im 90-100-Bit-Bereich zu. Obwohl realistisch, würde das niemand (nicht einmal die NSA) tun. Das Kosten-Nutzen-Verhältnis verrät das nicht. Social Engineering oder Folter, gefolgt von Mord, ist ein viel billigerer, schnellerer und praktischer Ansatz.

Für alles, was merklich größer als 110 Bit ist, ist ein Brute-Force-Angriff nicht realistisch, selbst wenn Sie das Kosten-Nutzen-Verhältnis vernachlässigen. Sie sollten sich mehr Sorgen über in AES integrierte Hintertüren machen, was mit größerer Wahrscheinlichkeit der Fall ist, als wenn Sie einen einzelnen 128-Bit-Schlüssel sehen, der während Ihres Aufenthalts durch rohe Gewalt gebrochen wurde Lebenszeit.

Die bloße Idee, einen 256-Bit-Schlüssel mit Brute Force zu knacken, ist geradezu lächerlich, und die Idee, darüber hinaus Bits hinzuzufügen, ist unsinnig und macht genau null Unterschied. Unmöglich geht es nicht besser als "unmöglich".

0
Damon