Wie wählt man einen AES-Verschlüsselungsmodus (CBC ECB CTR OCB CFB)?

Question

Welche von ihnen werden unter welchen Umständen bevorzugt?

Ich würde gerne die Liste der Bewertungskriterien für die verschiedenen Modi sehen und vielleicht eine Diskussion über die Anwendbarkeit der einzelnen Kriterien.

Zum Beispiel, Ich denke, eines der Kriterien ist die "Größe des Codes" für die Ver- und Entschlüsselung, was für eingebettete Systeme mit Mikrocode, wie 802.11-Netzwerkadapter, wichtig ist. WENN der für die Implementierung von CBC erforderliche Code viel kleiner ist als der für CTR (ich weiß nicht, ob das stimmt, es ist nur ein Beispiel), dann könnte ich verstehen, warum der Modus mit dem kleineren Code bevorzugt wird. Aber wenn ich eine Anwendung schreibe, die auf einem Server läuft, und die AES-Bibliothek, die ich verwende, implementiert ohnehin sowohl CBC als auch CTR, dann ist dieses Kriterium irrelevant.

Sehen Sie, was ich mit "Liste der Bewertungskriterien und Anwendbarkeit der einzelnen Kriterien" meine?

Das hat nicht wirklich etwas mit Programmierung zu tun, sondern mit Algorithmen.

Answer 1

Überlegen Sie sich gut, ob Sie nicht doch eine eigene Kryptographie implementieren können

Die hässliche Wahrheit ist, dass Sie, wenn Sie sich diese Frage stellen, wahrscheinlich nicht in der Lage sind, ein sicheres System zu entwerfen und zu implementieren.

Zur Veranschaulichung: Stellen Sie sich vor, Sie bauen eine Webanwendung und müssen einige Sitzungsdaten speichern. Sie könnten jedem Benutzer eine Sitzungs-ID zuweisen und die Sitzungsdaten auf dem Server in einer Hash-Map speichern, die die Sitzungs-ID den Sitzungsdaten zuordnet. Aber dann müssen Sie sich mit diesem lästigen Zustand auf dem Server auseinandersetzen, und wenn Sie irgendwann mehr als einen Server benötigen, wird es unübersichtlich. Daher haben Sie die Idee, die Sitzungsdaten in einem Cookie auf der Client-Seite zu speichern. Natürlich verschlüsseln Sie es, damit der Benutzer die Daten nicht lesen und manipulieren kann. Welchen Modus sollten Sie also verwenden? Wenn Sie hierher kommen, lesen Sie die erste Antwort (entschuldigen Sie, dass ich Sie herausgegriffen habe, myforwik). Der erste - ECB - ist nichts für dich, du willst mehr als einen Block verschlüsseln, der nächste - CBC - klingt gut und du brauchst die Parallelität von CTR nicht, du brauchst keinen zufälligen Zugriff, also kein XTS und Patente sind eine PITA, also kein OCB. Wenn Sie Ihre Krypto-Bibliothek verwenden, stellen Sie fest, dass Sie eine Auffüllung benötigen, da Sie nur ein Vielfaches der Blockgröße verschlüsseln können. Sie wählen PKCS7 weil es in einigen seriösen Kryptographienormen definiert wurde. Nachdem ich irgendwo gelesen habe, dass CBC nachweislich sicher in Verbindung mit einem zufälligen IV und einer sicheren Blockchiffre können Sie beruhigt sein, auch wenn Sie Ihre sensiblen Daten auf der Client-Seite speichern.

Jahre später, nachdem Ihr Dienst tatsächlich eine beträchtliche Größe erreicht hat, kontaktiert Sie ein IT-Sicherheitsspezialist im Rahmen einer verantwortungsvollen Offenlegung. Sie teilt Ihnen mit, dass sie alle Ihre Cookies mit Hilfe eines Tools entschlüsseln kann. Padding-Orakel-Angriff denn Ihr Code erzeugt eine Fehlerseite, wenn die Auffüllung irgendwie kaputt ist.

Dies ist kein hypothetisches Szenario: Microsoft hatte bis vor ein paar Jahren genau diese Schwachstelle in ASP.NET.

Das Problem ist, dass es bei der Kryptographie viele Fallstricke gibt und es extrem einfach ist, ein System zu bauen, das für den Laien sicher aussieht, aber für einen erfahrenen Angreifer leicht zu knacken ist.

Was ist zu tun, wenn Sie Daten verschlüsseln müssen?

Für Live-Verbindungen verwenden Sie TLS (achten Sie darauf, den Hostnamen des Zertifikats und die Ausstellerkette zu überprüfen). Wenn Sie TLS nicht verwenden können, suchen Sie nach der API auf höchster Ebene, die Ihr System für Ihre Aufgabe anbietet, und vergewissern Sie sich, dass Sie wissen, welche Garantien sie bietet und vor allem, was sie nicht garantiert. Für das obige Beispiel wäre ein Framework wie Spielen Angebote kundenseitige Speichereinrichtungen Allerdings werden die gespeicherten Daten nach einiger Zeit nicht ungültig, und wenn Sie den Status auf der Client-Seite geändert haben, kann ein Angreifer einen früheren Status wiederherstellen, ohne dass Sie es merken.

Wenn keine hochrangige Abstraktion verfügbar ist, verwenden Sie eine hochrangige Krypto-Bibliothek. Ein bekanntes Beispiel ist NaCl und eine portable Implementierung mit vielen Sprachbindungen ist Natrium . Bei der Verwendung einer solchen Bibliothek müssen Sie sich nicht um Verschlüsselungsmodi usw. kümmern, aber Sie müssen noch sorgfältiger auf die Nutzungsdetails achten als bei einer höheren Abstraktionsebene, z. B. dürfen Sie eine Nonce nie zweimal verwenden. Für die Erstellung eigener Protokolle (z.B. TLS, aber nicht über TCP oder UDP) gibt es Frameworks wie Lärm und die zugehörigen Implementierungen, die Ihnen die meiste Arbeit abnehmen, aber ihre Flexibilität bedeutet auch, dass es viel Raum für Fehler gibt, wenn Sie nicht genau verstehen, was die einzelnen Komponenten tun.

Wenn Sie aus irgendeinem Grund eine hochrangige Krypto-Bibliothek nicht verwenden können, weil Sie zum Beispiel auf eine bestimmte Art und Weise mit einem bestehenden System interagieren müssen, führt kein Weg daran vorbei, sich gründlich zu informieren. Ich empfehle die Lektüre Kryptographietechnik von Ferguson, Kohno und Schneier . Machen Sie sich bitte nicht vor, dass Sie ohne das nötige Hintergrundwissen ein sicheres System aufbauen können. Kryptographie ist extrem subtil und es ist nahezu unmöglich, die Sicherheit eines Systems zu testen.

Vergleich der Modi

Nur Verschlüsselung:

• Modi, die Polsterung erfordern : Wie im Beispiel kann das Auffüllen im Allgemeinen gefährlich sein, weil es die Möglichkeit von Auffüll-Orakel-Angriffen eröffnet. Die einfachste Verteidigung besteht darin, jede Nachricht vor der Entschlüsselung zu authentifizieren. Siehe unten.
  • EZB verschlüsselt jeden Datenblock unabhängig voneinander, und der gleiche Klartextblock ergibt den gleichen Chiffretextblock. Werfen Sie einen Blick auf das EZB-verschlüsselte Tux-Bild auf der EZB-Wikipedia-Seite um zu verstehen, warum dies ein ernstes Problem ist. Mir ist kein Anwendungsfall bekannt, in dem die EZB akzeptabel wäre.
  • CBC hat einen IV und benötigt daher jedes Mal, wenn eine Nachricht verschlüsselt wird, Zufälligkeit, die Änderung eines Teils der Nachricht erfordert die erneute Verschlüsselung des gesamten Textes nach der Änderung, Übertragungsfehler in einem Chiffretextblock zerstören den Klartext vollständig und verändern die Entschlüsselung des nächsten Blocks, die Entschlüsselung kann parallelisiert werden / die Verschlüsselung nicht, der Klartext ist bis zu einem gewissen Grad formbar - dies kann ein Problem sein .
• Stromverschlüsselungsmodi : Diese Modi erzeugen einen pseudozufälligen Datenstrom, der mit dem Klartext übereinstimmen kann oder auch nicht. Ähnlich wie bei Stromchiffren im Allgemeinen wird der erzeugte Pseudozufallsstrom mit dem Klartext XOR-verknüpft, um den Chiffretext zu erzeugen. Da man so viele Bits des Zufallsstroms verwenden kann, wie man will, braucht man kein Padding. Der Nachteil dieser Einfachheit ist, dass die Verschlüsselung vollständig Formbare Das bedeutet, dass die Entschlüsselung von einem Angreifer beliebig verändert werden kann, denn für einen Klartext p1, einen Geheimtext c1 und einen Pseudozufallsstrom r kann der Angreifer eine Differenz d wählen, so dass die Entschlüsselung eines Geheimtextes c2=c1d p2 = p1d ist, da p2 = c2r = (c1 d) r = d (c1 r). Außerdem darf derselbe Pseudozufallsstrom nie zweimal verwendet werden, da ein Angreifer für zwei Chiffretexte c1=p1r und c2=p2r das xor der beiden Klartexte als c1c2=p1rp2r=p1p2 berechnen kann. Das bedeutet auch, dass eine Änderung der Nachricht eine vollständige Neuverschlüsselung erfordert, wenn die ursprüngliche Nachricht von einem Angreifer hätte erlangt werden können. Alle folgenden Dampf-Chiffre-Modi benötigen nur die Verschlüsselungsoperation der Blockchiffre, so dass je nach Chiffre in extrem eingeschränkten Umgebungen etwas (Silizium- oder Maschinencode) Platz gespart werden kann.
  • CTR ist einfach, es erzeugt einen Pseudo-Zufallsstrom, der unabhängig vom Klartext ist, verschiedene Pseudo-Zufallsströme werden durch Hochzählen von verschiedenen Nonces/IVs erhalten, die mit einer maximalen Nachrichtenlänge multipliziert werden, so dass Überschneidungen verhindert werden, mit Nonces ist Nachrichtenverschlüsselung ohne Zufälligkeit pro Nachricht möglich, Ent- und Verschlüsselung sind vollständig parallelisierbar, Übertragungsfehler betreffen nur die falschen Bits und nichts weiter
  • OFB erzeugt auch einen vom Klartext unabhängigen Pseudo-Zufallsstrom, verschiedene Pseudo-Zufallsströme werden erhalten, indem für jede Nachricht mit einer anderen Nonce oder Zufalls-IV begonnen wird, weder Ver- noch Entschlüsselung ist arallelisierbar, wie bei CTR ist die Verschlüsselung von Nachrichten mit Nonces ohne Zufälligkeit pro Nachricht möglich, wie bei CTR wirken sich Übertragungsfehler nur auf die falschen Bits aus, mehr nicht
  • CFB Der Pseudo-Zufallsstrom hängt vom Klartext ab, für jede Nachricht wird eine andere Nonce oder Zufalls-IV benötigt, wie bei CTR und OFB mit Nonces ist Nachrichtenverschlüsselung ohne Zufälligkeit pro Nachricht möglich, Entschlüsselung ist parallelisierbar / Verschlüsselung nicht, Übertragungsfehler zerstören den folgenden Block komplett, wirken sich aber nur auf die falschen Bits im aktuellen Block aus
• Modi der Festplattenverschlüsselung : Diese Modi sind darauf spezialisiert, Daten unterhalb der Dateisystemabstraktion zu verschlüsseln. Aus Gründen der Effizienz darf das Ändern einiger Daten auf dem Datenträger nur das Neuschreiben von höchstens einem Datenträgerblock (512 Byte oder 4kib) erfordern. Sie fallen nicht in den Rahmen dieser Antwort, da sie ganz andere Anwendungsszenarien haben als die anderen. Verwenden Sie sie für nichts anderes als für die Verschlüsselung auf Blockebene . Einige Mitglieder: XEX, XTS, LRW.

Authentifizierte Verschlüsselung:

Um Padding-Orakel-Angriffe und Änderungen am Chiffretext zu verhindern, kann man eine Nachrichten-Authentifizierungs-Code (MAC) auf den Chiffretext und entschlüsseln ihn nur, wenn er nicht manipuliert wurde. Dies wird als Verschlüsseln-dann-MAC bezeichnet und sollte vor jeder anderen Reihenfolge bevorzugt werden . Abgesehen von sehr wenigen Anwendungsfällen ist die Authentizität ebenso wichtig wie die Vertraulichkeit (letztere ist das Ziel der Verschlüsselung). Authentifizierte Verschlüsselungsverfahren (mit zugehörigen Daten (AEAD)) kombinieren den zweiteiligen Prozess der Verschlüsselung und Authentifizierung in einem Blockchiffrierverfahren, das dabei auch ein Authentifizierungskennzeichen erzeugt. In den meisten Fällen führt dies zu einer Verbesserung der Geschwindigkeit.

• CCM ist eine einfache Kombination aus dem CTR-Modus und einem CBC-MAC. Mit zwei Blockchiffre-Verschlüsselungen pro Block ist es sehr langsam.
• OCB ist schneller, aber durch Patente belastet. Für freie (wie in Freiheit) oder nicht-militärische Software muss der Patentinhaber hat eine kostenlose Lizenz erteilt Allerdings.
• GCM ist eine sehr schnelle, aber argumentativ komplexe Kombination aus CTR-Modus und GHASH, einem MAC über das Galois-Feld mit 2^128 Elementen. Seine breite Verwendung in wichtigen Netzwerkstandards wie TLS 1.2 spiegelt sich in einem besondere Anweisung Intel hat eingeführt, um die Berechnung von GHASH zu beschleunigen.

Empfehlung:

In Anbetracht der Bedeutung der Authentifizierung würde ich die folgenden beiden Blockchiffriermodi für die meisten Anwendungsfälle empfehlen (außer für Festplattenverschlüsselung): Wenn die Daten durch eine asymmetrische Signatur authentifiziert sind, verwenden Sie CBC, ansonsten GCM.

Answer 2

• ECB sollte nicht verwendet werden, wenn mehr als ein Datenblock mit demselben Schlüssel verschlüsselt wird.

• CBC, OFB und CFB sind ähnlich, aber OFB/CFB ist besser, weil man nur die Verschlüsselung und nicht die Entschlüsselung braucht, was Codeplatz sparen kann.

• CTR wird verwendet, wenn Sie eine gute Parallelisierung (d.h. Geschwindigkeit) wünschen, anstelle von CBC/OFB/CFB.

• Der XTS-Modus ist der gebräuchlichste, wenn Sie Daten mit wahlfreiem Zugriff kodieren (z. B. eine Festplatte oder RAM).

• OCB ist bei weitem der beste Modus, da er Verschlüsselung und Authentifizierung in einem einzigen Durchgang ermöglicht. Allerdings gibt es in den USA Patente auf dieses Verfahren.

Das Einzige, was Sie wirklich wissen müssen, ist, dass ECB nicht verwendet werden sollte, es sei denn, Sie verschlüsseln nur einen Block. XTS sollte verwendet werden, wenn Sie Daten verschlüsseln, auf die zufällig zugegriffen wird, und nicht einen Datenstrom.

• Sie sollten IMMER eindeutige IV jedes Mal, wenn Sie verschlüsseln, und sie sollten zufällig . Wenn Sie nicht garantieren können, dass sie zufällig OCB verwenden, da es nur eine nonce , nicht ein IV und es gibt einen deutlichen Unterschied. A nonce die Sicherheit nicht beeinträchtigt, wenn die Leute die nächste Zahl erraten können, ein IV kann dieses Problem verursachen.

Answer 3

Eine formale Analyse wurde von Phil Rogaway im Jahr 2011 durchgeführt, aquí . Abschnitt 1.6 enthält eine Zusammenfassung, die ich hier wiedergebe, wobei ich meine eigene Hervorhebung in Fettdruck hinzufüge (wenn Sie ungeduldig sind, empfiehlt er die Verwendung des CTR-Modus, aber ich schlage vor, dass Sie meine Abschnitte über Nachrichtenintegrität und Verschlüsselung weiter unten lesen).

Beachten Sie, dass die meisten von ihnen verlangen, dass der IV zufällig ist, was bedeutet, dass er nicht vorhersehbar ist und daher mit kryptographischer Sicherheit erzeugt werden sollte. Einige verlangen jedoch nur einen "nonce", der diese Eigenschaft nicht erfordert, sondern nur, dass er nicht wiederverwendet wird. Daher sind Entwürfe, die sich auf eine Nonce stützen, weniger fehleranfällig als Entwürfe, die dies nicht tun (und glauben Sie mir, ich habe viele Fälle gesehen, in denen CBC nicht mit einer angemessenen IV-Auswahl implementiert wurde). Sie sehen also, dass ich fett gedruckt habe, wenn Rogaway etwas sagt wie "Vertraulichkeit wird nicht erreicht, wenn die IV eine Nonce ist", dann bedeutet das, dass es kein Problem ist, wenn Sie Ihre IV kryptographisch sicher (unvorhersehbar) wählen. Aber wenn Sie das nicht tun, dann verlieren Sie die guten Sicherheitseigenschaften. Niemals eine Infusion wiederverwenden für jeden dieser Modi.

Außerdem ist es wichtig, den Unterschied zwischen Nachrichtenintegrität und Verschlüsselung zu verstehen. Die Verschlüsselung verbirgt Daten, aber ein Angreifer kann die verschlüsselten Daten verändern, und die Ergebnisse können möglicherweise von Ihrer Software akzeptiert werden, wenn Sie die Nachrichtenintegrität nicht überprüfen. Während der Entwickler sagen wird: "Aber die geänderten Daten kommen nach der Entschlüsselung als Müll zurück", wird ein guter Sicherheitsingenieur die Wahrscheinlichkeit ermitteln, dass der Müll ein unerwünschtes Verhalten in der Software hervorruft, und dann wird er diese Analyse in einen echten Angriff umsetzen. Ich habe schon viele Fälle gesehen, in denen Verschlüsselung eingesetzt wurde, aber die Integrität der Nachricht wirklich wichtiger war als die Verschlüsselung. Verstehen Sie, was Sie brauchen.

Ich sollte sagen, dass GCM, obwohl es sowohl Verschlüsselung als auch Nachrichtenintegrität bietet, ein sehr anfälliges Design ist: Wenn Sie eine IV wiederverwenden, sind Sie aufgeschmissen - der Angreifer kann Ihren Schlüssel wiederherstellen. Andere Entwürfe sind weniger anfällig, daher habe ich persönlich Angst, GCM zu empfehlen, da ich in der Praxis viele schlechte Verschlüsselungscodes gesehen habe.

Wenn Sie beides brauchen, Nachrichtenintegrität und Verschlüsselung, können Sie zwei Algorithmen kombinieren: normalerweise sehen wir CBC mit HMAC, aber es gibt keinen Grund, sich an CBC zu binden. Wichtig zu wissen ist erst verschlüsseln, dann MAC der verschlüsselten Inhalte und nicht andersherum. Außerdem muss die IV in die MAC-Berechnung einbezogen werden.

Mir sind keine IP-Probleme bekannt.

Und nun zu den guten Sachen von Professor Rogaway:

Blockchiffre-Modi, Verschlüsselung, aber keine Nachrichtenintegrität

EZB : Als Blockchiffrierer verschlüsselt dieser Modus Nachrichten, die ein Vielfaches von n Bits sind, indem jedes n-Bit-Stück einzeln verschlüsselt wird. Die Sicherheitseigenschaften sind schwach Die Methode lässt die Gleichheit der Blöcke sowohl über die Blockpositionen als auch über die Zeit erkennen. Das Verfahren ist von beträchtlichem Wert für das Erbe und als Baustein für andere Verfahren, erreicht aber für sich genommen kein allgemein wünschenswertes Sicherheitsziel und muss mit großer Vorsicht verwendet werden; Die EZB sollte nicht als "Allzweck"-Vertraulichkeitsmodus betrachtet werden. .

CBC : Als IV-basiertes Verschlüsselungsverfahren ist der Modus sicher wie ein probabilistisches Verschlüsselungsverfahren, das unter der Annahme eines zufälligen IV keine Unterscheidbarkeit von Zufallsbits erreicht. Die Vertraulichkeit ist nicht gegeben, wenn der IV lediglich ein Nonce ist. und auch nicht, wenn es sich um eine Nonce handelt, die mit demselben Schlüssel verschlüsselt wurde, der auch im Schema verwendet wird, wie es die Norm fälschlicherweise vorschlägt. Chiffretexte sind in hohem Maße formbar. Keine Sicherheit beim Chiffriertext-Angriff (CCA). Die Vertraulichkeit geht bei vielen Auffüllmethoden verloren, wenn ein Orakel für korrektes Auffüllen vorhanden ist. Die Verschlüsselung ist ineffizient, da sie von Natur aus seriell ist. Die weit verbreiteten Sicherheitseigenschaften des Modus, der nur die Privatsphäre schützt, führen zu häufigem Missbrauch. Kann als Baustein für CBC-MAC-Algorithmen verwendet werden. Ich kann keine wesentlichen Vorteile gegenüber dem CTR-Modus erkennen.

CFB : Als IV-basiertes Verschlüsselungsverfahren ist der Modus sicher wie ein probabilistisches Verschlüsselungsverfahren, das unter der Annahme eines zufälligen IV keine Unterscheidbarkeit von Zufallsbits erreicht. Die Vertraulichkeit ist nicht gegeben, wenn die Infusion vorhersehbar ist. noch durch eine Nonce, die mit demselben Schlüssel verschlüsselt wird, der auch für das Verfahren verwendet wird, wie die Norm fälschlicherweise vorschlägt. Chiffriertexte sind formbar. Keine CCA-Sicherheit. Die Verschlüsselung ist ineffizient, da sie von Natur aus seriell ist. Das Verfahren hängt von einem Parameter s, 1 s n ab, typischerweise s = 1 oder s = 8. Ineffizient, da ein Blockchiffrieraufruf benötigt wird, um nur s Bits zu verarbeiten. Der Modus erreicht eine interessante "Selbstsynchronisierungs"-Eigenschaft; das Einfügen oder Löschen einer beliebigen Anzahl von s-Bit-Zeichen in den Chiffretext unterbricht nur vorübergehend die korrekte Entschlüsselung.

OFB : Als IV-basiertes Verschlüsselungsverfahren ist der Modus sicher wie ein probabilistisches Verschlüsselungsverfahren, das unter der Annahme eines zufälligen IV keine Unterscheidbarkeit von Zufallsbits erreicht. Die Vertraulichkeit wird nicht erreicht, wenn die IV ein Nonce ist, obwohl eine feste Folge von IVs (z.B. ein Zähler) gut funktioniert. Chiffretexte sind in hohem Maße formbar. Keine CCA-Sicherheit. Ver- und Entschlüsselung sind ineffizient, da sie von Natur aus seriell sind. Verschlüsselt nativ Zeichenketten beliebiger Bitlänge (kein Auffüllen erforderlich). Ich kann keine wichtigen Vorteile gegenüber dem CTR-Modus erkennen.

CTR : Als IV-basiertes Verschlüsselungsverfahren erreicht der Modus eine Ununterscheidbarkeit von Zufallsbits unter der Annahme eines Nonce IV. Als sicheres nonce-basiertes Verfahren kann der Modus auch als probabilistisches Verschlüsselungsverfahren mit einer zufälligen IV verwendet werden. Vollständiges Versagen der Privatsphäre, wenn ein Nonce bei der Ver- oder Entschlüsselung wiederverwendet wird. Die Parallelisierbarkeit des Verfahrens macht es oft schneller, in einigen Fällen sogar viel schneller als andere Vertraulichkeitsverfahren. Ein wichtiger Baustein für authentifizierte Verschlüsselungsverfahren. Insgesamt ist dies in der Regel der beste und modernste Weg, um eine Verschlüsselung zu erreichen, die nur der Privatsphäre dient.

XTS : Bei diesem IV-basierten Verschlüsselungsverfahren wird auf jedes n-Bit-Stück eine veränderbare Blockchiffre (sicher wie ein Strong-PRP) angewendet. Bei Nachrichten, deren Länge nicht durch n teilbar ist, werden die letzten beiden Blöcke besonders behandelt. Die einzige zulässige Verwendung dieses Modus ist die Verschlüsselung von Daten auf einem blockstrukturierten Speichergerät. Die geringe Breite des zugrundeliegenden PRP und die schlechte Behandlung von gebrochenen Endblöcken sind problematisch. Effizienter, aber weniger wünschenswert als eine (breite) PRP-sichere Blockchiffre wäre.

MACs (Nachrichtenintegrität, aber keine Verschlüsselung)

ALG1-6 : Eine Sammlung von MACs, die alle auf dem CBC-MAC basieren. Zu viele Schemata. Einige sind nachweislich sicher als VIL-PRFs, einige als FIL-PRFs, und einige haben keine nachweisbare Sicherheit. Einige der Verfahren lassen schädliche Angriffe zu. Einige der Verfahren sind veraltet. Bei den Verfahren, die über eine Schlüsselseparation verfügen, wird diese nur unzureichend berücksichtigt. Es sollte nicht massenhaft angenommen werden, aber eine selektive Auswahl der "besten" Verfahren ist möglich. Es wäre auch in Ordnung, keinen dieser Modi zu übernehmen, sondern CMAC zu bevorzugen. Einige der ISO 9797-1 MACs sind weithin genormt und werden verwendet, insbesondere im Bankwesen. Eine überarbeitete Version der Norm (ISO/IEC FDIS 9797-1:2010) wird demnächst veröffentlicht [93].

CMAC : Ein MAC auf der Grundlage des CBC-MAC, der Modus ist nachweislich sicher (bis zur Geburtstagsgrenze) als (VIL) PRF (vorausgesetzt, die zugrundeliegende Blockchiffre ist eine gute PRP). Im Wesentlichen minimaler Overhead für ein CBCMAC-basiertes Verfahren. Die inhärent serielle Natur stellt in einigen Anwendungsbereichen ein Problem dar, und die Verwendung mit einer 64-Bit-Blockverschlüsselung würde ein gelegentliches Neuschlüsseln erforderlich machen. Sauberer als die ISO 9797-1 Sammlung von MACs.

HMAC : Ein MAC, der auf einer kryptografischen Hash-Funktion und nicht auf einer Blockchiffre basiert (obwohl die meisten kryptografischen Hash-Funktionen selbst auf Blockchiffren basieren). Der Mechanismus verfügt über starke beweisbare Sicherheitsgrenzen, wenn auch nicht unter den bevorzugten Annahmen. Mehrere eng verwandte Varianten in der Literatur erschweren das Verständnis des Bekannten. Es wurden noch keine schädlichen Angriffe vorgeschlagen. Weithin standardisiert und verwendet.

GMAC : Ein nonce-basierter MAC, der ein Spezialfall von GCM ist. Vererbt viele der guten und schlechten Eigenschaften von GCM. Aber die nonce-Anforderung ist für einen MAC unnötig und bringt hier wenig Nutzen. Praktische Angriffe, wenn die Tags auf 64 Bit gekürzt werden und der Umfang der Entschlüsselung nicht überwacht und eingeschränkt wird. Vollständiges Versagen bei der Nonce-Wiederverwendung. Die Verwendung ist ohnehin implizit, wenn GCM angenommen wird. Nicht für eine separate Normung empfohlen.

authentifizierte Verschlüsselung (sowohl Verschlüsselung als auch Nachrichtenintegrität)

CCM : Ein nonce-basiertes AEAD-Verfahren, das die Verschlüsselung im CTR-Modus mit der rohen CBC-MAC. Inhärent seriell, was die Geschwindigkeit in einigen Kontexten einschränkt. Nachweislich sicher, mit guten Grenzen, vorausgesetzt, die zugrunde liegende Blockchiffre ist eine gute PRP. Unkomplizierte Konstruktion, die die Aufgabe nachweislich erfüllt. Einfacher zu implementieren als GCM. Kann als nonce-basierter MAC verwendet werden. Weitgehend standardisiert und verwendet.

GCM : Ein nonce-basiertes AEAD-Verfahren, das die Verschlüsselung im CTR-Modus und eine universelle Hash-Funktion auf GF(2128)-Basis kombiniert. Gute Effizienzmerkmale für einige Implementierungsumgebungen. Gute beweisbar sichere Ergebnisse unter der Annahme minimaler Tag-Trunkierung. Angriffe und schlechte beweisbare Sicherheitsgrenzen bei erheblicher Tag-Trunkierung. Kann als nonce-basierter MAC verwendet werden, der dann GMAC genannt wird. Fragwürdige Entscheidung, andere Nonces als 96-Bits zuzulassen. Es wird empfohlen, Nonces auf 96 Bits und Tags auf mindestens 96 Bits zu beschränken. Weitgehend standardisiert und verwendet.

Answer 4

1. Alles, nur nicht die EZB.
2. Wenn Sie CTR verwenden, müssen Sie unbedingt für jede Nachricht einen anderen IV verwenden, da der Angreifer sonst in der Lage ist, zwei Chiffretexte zu nehmen und daraus einen kombinierten unverschlüsselten Klartext abzuleiten. Der Grund dafür ist, dass der CTR-Modus eine Blockchiffre im Wesentlichen in eine Stromchiffre verwandelt, und die erste Regel von Stromchiffren lautet, niemals denselben Schlüssel+IV zweimal zu verwenden.
3. Der Schwierigkeitsgrad der einzelnen Modi ist nicht sehr unterschiedlich. Bei einigen Modi muss die Blockchiffre nur in der Verschlüsselungsrichtung arbeiten. Die meisten Blockchiffren, einschließlich AES, benötigen jedoch nicht viel mehr Code, um die Entschlüsselung zu implementieren.
4. Bei allen Verschlüsselungsmodi ist es wichtig, für jede Nachricht unterschiedliche IVs zu verwenden, wenn Ihre Nachrichten in den ersten paar Bytes identisch sein könnten und Sie nicht wollen, dass ein Angreifer dies weiß.

Answer 5

Lesen Sie zunächst die Informationen auf Wikipedia zu diesem Thema - Funktionsweise von Blockchiffren ? Dann folgen Sie dem Referenzlink auf Wikipedia zu NIST: Empfehlung für Block Cipher Modes of Operation .