it-swarm.com.de

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

Welche von ihnen werden unter welchen Umständen bevorzugt?

Ich möchte die Liste der Bewertungskriterien für die verschiedenen Modi und möglicherweise eine Diskussion über die Anwendbarkeit der einzelnen Kriterien sehen.

Zum Beispiel denke ich, dass eines der Kriterien die "Größe des Codes" für die Ver- und Entschlüsselung ist, was für eingebettete Mikrocodesysteme wie 802.11-Netzwerkadapter wichtig ist. WENN der Code, der für die Implementierung von CBC erforderlich ist, viel kleiner ist als der für die Klickrate (ich weiß nicht, dass dies zutrifft, es ist nur ein Beispiel), könnte ich verstehen, warum der Modus mit dem kleineren Code bevorzugt würde. Wenn ich jedoch eine App schreibe, die auf einem Server ausgeführt wird, und die von mir verwendete AES-Bibliothek sowieso sowohl CBC als auch CTR implementiert, ist dieses Kriterium irrelevant.

Sehen Sie, was ich mit "Liste der Bewertungskriterien und Anwendbarkeit jedes Kriteriums" meine?

Dies ist nicht wirklich programmierbezogen, sondern algorithmisch.

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

  • CBC, OFB und CFB sind ähnlich, OFB/CFB ist jedoch besser, da Sie nur Verschlüsselung und nicht Entschlüsselung benötigen, wodurch Codeplatz gespart werden kann.

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

  • Der XTS-Modus ist am gebräuchlichsten, wenn Sie zufällig zugängliche Daten codieren (z. B. eine Festplatte oder ein RAM).

  • OCB ist bei weitem der beste Modus, da es die Verschlüsselung und Authentifizierung in einem Durchgang ermöglicht. In den USA gibt es jedoch Patente.

Das einzige, was Sie wirklich wissen müssen, ist, dass die EZB nur verwendet werden darf, wenn Sie nur einen Block verschlüsseln. XTS sollte verwendet werden, wenn Sie Daten verschlüsseln, auf die zufällig zugegriffen wird, und keinen Stream.

  • Sie sollten bei jeder Verschlüsselung IMMER eindeutige IV verwenden, und diese sollten zufällig sein. Wenn Sie nicht garantieren können, dass sie zufällig sind, verwenden Sie OCB, da dies nur ein nonce und kein IV erfordert und es einen deutlichen Unterschied gibt . Ein nonce setzt die Sicherheit nicht außer Kraft, wenn Personen die nächste erraten können. Ein IV kann dieses Problem verursachen.
292
myforwik

Bitte überlegen Sie lange und gründlich, ob Sie Ihre eigene Kryptografie nicht implementieren können

Die hässliche Wahrheit ist, dass Sie, wenn Sie diese Frage stellen, wahrscheinlich kein sicheres System entwerfen und implementieren können.

Lassen Sie mich meinen Punkt veranschaulichen: Stellen Sie sich vor, Sie erstellen eine Webanwendung und müssen einige Sitzungsdaten speichern. Sie können 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 muss man sich mit diesem nervigen Zustand auf dem Server auseinandersetzen und wenn man irgendwann mehr als einen Server braucht, werden die Dinge chaotisch. Stattdessen haben Sie die Idee, die Sitzungsdaten in einem Cookie auf der Clientseite zu speichern. Sie werden es natürlich verschlüsseln, damit der Benutzer die Daten nicht lesen und manipulieren kann. Welchen Modus sollten Sie also verwenden? Wenn Sie hierher kommen, lesen Sie die beste Antwort (entschuldigen Sie, dass Sie myforwik ausgewählt haben). Die erste - EZB - ist nichts für Sie, Sie möchten mehr als einen Block verschlüsseln, die nächste - CBC - klingt gut und Sie benötigen keine CTR-Parallelität, Sie benötigen keinen Direktzugriff, also nein XTS und Patente sind eine PITA, also kein OCB. Wenn Sie Ihre Kryptobibliothek 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 Kryptografiestandards definiert wurde. Nachdem Sie irgendwo gelesen haben, dass CBC nachweislich sicher ist, wenn es mit einer zufälligen IV und einer sicheren Blockverschlüsselung verwendet wird, können Sie beruhigt sein, obwohl Sie Ihre vertraulichen Daten auf der Clientseite speichern.

Jahre später, nachdem Ihr Service tatsächlich zu einer bedeutenden Größe angewachsen ist, kontaktiert Sie ein IT-Sicherheitsspezialist, um eine verantwortungsvolle Offenlegung vorzunehmen. Sie sagt dir, dass sie alle deine Cookies mit einem padding Oracle attack entschlüsseln kann, weil dein Code eine Fehlerseite erzeugt, wenn die Auffüllung irgendwie kaputt ist.

Dies ist kein hypothetisches Szenario: Microsoft hatte bis vor einigen Jahren genau diesen Fehler in ASP.NET.

Das Problem ist, dass es viele Fallstricke in Bezug auf Kryptografie gibt und es extrem einfach ist, ein System zu erstellen, das für den Laien sicher aussieht, für einen sachkundigen Angreifer jedoch trivial zu knacken ist.

Was tun, wenn Daten verschlüsselt werden müssen?

Verwenden Sie für Live-Verbindungen TLS (überprüfen Sie unbedingt den Hostnamen des Zertifikats und die Ausstellerkette). Wenn Sie TLS nicht verwenden können, suchen Sie nach der API der höchsten Ebene, die Ihr System für Ihre Aufgabe bietet, und vergewissern Sie sich, dass Sie die angebotenen Garantien und vor allem die Garantien verstehen, die es nicht bietet. Für das obige Beispiel bietet ein Framework wie Play clientseitige Speichermöglichkeiten , die gespeicherten Daten werden jedoch nach einiger Zeit und nach einer Änderung nicht ungültig Im clientseitigen Status kann ein Angreifer einen vorherigen Status wiederherstellen, ohne dass Sie dies bemerken.

Wenn keine Abstraktion auf hoher Ebene verfügbar ist, verwenden Sie eine Kryptobibliothek auf hoher Ebene. Ein prominentes Beispiel ist NaCl und eine portable Implementierung mit vielen Sprachbindungen ist Natrium . Wenn Sie eine solche Bibliothek verwenden, müssen Sie sich nicht um Verschlüsselungsmodi usw. kümmern, sondern müssen noch sorgfältiger mit den Verwendungsdetails umgehen als mit einer Abstraktion auf höherer Ebene, wie wenn Sie eine Nonce nie zweimal verwenden.

Wenn Sie aus irgendeinem Grund keine hochrangige Kryptobibliothek verwenden können, weil Sie beispielsweise auf bestimmte Weise mit dem vorhandenen System interagieren müssen, führt kein Weg an einer gründlichen Schulung vorbei. Ich empfehle Cryptography Engineering von Ferguson, Kohno und Schneier . Bitte täuschen Sie sich nicht in der Annahme, dass Sie ein sicheres System ohne den erforderlichen Hintergrund aufbauen können. Kryptografie ist äußerst subtil und es ist nahezu unmöglich, die Sicherheit eines Systems zu testen.

Vergleich der Modi

Nur Verschlüsselung:

  • Modi, die ein Auffüllen erfordern : Wie im Beispiel kann das Auffüllen im Allgemeinen gefährlich sein, da es die Möglichkeit eröffnet, Oracle-Angriffe aufzufüllen. Die einfachste Verteidigung besteht darin, jede Nachricht vor der Entschlüsselung zu authentifizieren. Siehe unten.
    • ECB verschlüsselt jeden Datenblock unabhängig und der gleiche Klartextblock führt zum gleichen Chiffretextblock. Schauen Sie sich das EZB-verschlüsselte Tux-Bild auf der EZB-Wikipedia-Seite an, um zu sehen, warum dies ein ernstes Problem ist. Ich kenne keinen Anwendungsfall, bei dem die EZB akzeptabel wäre.
    • CBC hat eine IV und muss daher jedes Mal zufällig ausgewählt werden, wenn eine Nachricht verschlüsselt wird. Wenn ein Teil der Nachricht geändert wird, muss nach der Änderung alles neu verschlüsselt werden. Übertragungsfehler in einem Chiffretextblock zerstören den Klartext vollständig und verändern die Entschlüsselung des nächsten Blocks, Entschlüsselung kann parallelisiert werden/Verschlüsselung nicht, der Klartext ist bis zu einem gewissen Grad formbar - dies kann ein Problem sein .
  • Stream-Verschlüsselungsmodi : Diese Modi erzeugen einen pseudozufälligen Datenstrom, der vom Klartext abhängt oder nicht. Ähnlich wie bei Stream-Chiffren wird der generierte Pseudozufallsstrom mit dem Klartext XOR-verknüpft, um den Chiffretext zu generieren. Da Sie so viele Teile des Zufallsstroms verwenden können, wie Sie möchten, müssen Sie überhaupt keine Auffüllungen vornehmen. Nachteil dieser Einfachheit ist, dass die Verschlüsselung vollständig formbar ist, was bedeutet, dass die Entschlüsselung von einem Angreifer beliebig geändert werden kann, wie für einen Klartext p1, einen Chiffretext c1 und einen Pseudozufallsstrom r und Angreifer können eine Differenz d so wählen, dass die Entschlüsselung eines Chiffretexts c2 = c1 cd p2 = p1⊕d ist, da p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Außerdem darf derselbe Pseudozufallsstrom niemals zweimal verwendet werden wie für zwei Chiffretexte c1 = p1⊕r und c2 = p2⊕r. Ein Angreifer kann das xor der beiden Klartexte als c1⊕c2 = p1⊕r⊕p2⊕r = berechnen p1⊕p2. Das bedeutet auch, dass das Ändern der Nachricht eine vollständige Neuverschlüsselung erfordert, wenn die ursprüngliche Nachricht von einem Angreifer erhalten werden könnte. Alle folgenden Steam-Verschlüsselungsmodi erfordern nur die Verschlüsselung der Blockverschlüsselung. Abhängig von der Verschlüsselung kann dies in extrem beengten Umgebungen Platz sparen (Silizium oder Maschinencode).
    • CTR ist einfach, es wird ein vom Klartext unabhängiger Pseudozufallsstrom erzeugt, verschiedene Pseudozufallsströme werden durch Hochzählen von verschiedenen Nonces erhalten/IVs, die mit einer maximalen Nachrichtenlänge multipliziert werden, um eine Überlappung zu verhindern, können mit nonces-Nachrichtenverschlüsselung ohne Zufälligkeit pro Nachricht, Entschlüsselung und Verschlüsselung parallelisierbar abgeschlossen werden, Übertragungsfehler bewirken nur die falschen Bits und nichts mehr
    • OFB erzeugt auch einen vom Klartext unabhängigen Pseudozufallsstrom, wobei verschiedene Pseudozufallsströme erhalten werden, indem für jede Nachricht mit einem anderen Nonce oder Zufalls-IV begonnen wird , weder Verschlüsselung noch Entschlüsselung ist parallelisierbar, da bei CTR mit Nonces eine Nachrichtenverschlüsselung ohne Per-Message-Randomness möglich ist, da bei CTR Übertragungsfehler nur die falschen Bits und nichts mehr bewirken
    • CFB Der Pseudozufallsstrom hängt vom Klartext ab. Für jede Nachricht wird ein anderer Nonce oder eine andere zufällige IV benötigt, wie bei CTR und OFB, die Nonces verwenden Nachrichtenverschlüsselung ist ohne Zufälligkeit der Nachricht möglich, Entschlüsselung ist parallelisierbar/Verschlüsselung nicht, Übertragungsfehler zerstören den folgenden Block vollständig, bewirken aber nur die falschen Bits im aktuellen Block
  • Festplattenverschlüsselungsmodi: Diese Modi sind darauf spezialisiert, Daten unterhalb der Dateisystemabstraktion zu verschlüsseln. Aus Gründen der Effizienz müssen zum Ändern einiger Daten auf der Disc nur höchstens ein Disc-Block (512 Byte oder 4 KB) überschrieben werden. Sie fallen nicht in den Geltungsbereich dieser Antwort, da sie ganz andere Verwendungsszenarien haben als die anderen. Verwenden Sie sie nur für die Blockverschlüsselung . Einige Mitglieder: XEX, XTS, LRW.

Authentifizierte Verschlüsselung:

Um das Auffüllen von Oracle-Angriffen und Änderungen am Chiffretext zu verhindern, kann ein Nachrichtenauthentifizierungscode (MAC) für den Chiffretext berechnet und nur entschlüsselt werden, wenn er nicht manipuliert wurde. Dies nennt man Encrypt-Then-Mac und sollte jeder anderen Reihenfolge vorgezogen werden . Mit Ausnahme von sehr wenigen Anwendungsfällen ist Authentizität genauso wichtig wie Vertraulichkeit (letztere ist das Ziel der Verschlüsselung). Authentifizierte Verschlüsselungsschemata (mit zugehörigen Daten (AEAD)) kombinieren den zweiteiligen Prozess der Verschlüsselung und Authentifizierung in einem Blockverschlüsselungsmodus, der dabei auch ein Authentifizierungs-Tag erzeugt. In den meisten Fällen führt dies zu einer Geschwindigkeitsverbesserung.

  • CCM ist eine einfache Kombination aus CTR-Modus und CBC-MAC. Bei Verwendung von zwei Blockverschlüsselungen pro Block ist dies sehr langsam.
  • OCB ist schneller, aber durch Patente belastet. Für freie (wie in Freiheit) oder nichtmilitärische Software hat der Patentinhaber jedoch eine freie Lizenz erteilt .
  • GCM ist eine sehr schnelle, aber wohl komplexe Kombination aus CTR-Modus und GHASH, einem MAC über dem Galois-Feld mit 2 ^ 128 Elementen. Der breite Einsatz in wichtigen Netzwerkstandards wie TLS 1.2 spiegelt sich in einer speziellen Anweisung wider, die Intel eingeführt hat, um die Berechnung von GHASH zu beschleunigen.

Empfehlung:

In Anbetracht der Wichtigkeit der Authentifizierung würde ich für die meisten Anwendungsfälle (außer für Festplattenverschlüsselungszwecke) die folgenden zwei Blockverschlüsselungsmodi empfehlen: Wenn die Daten durch eine asymmetrische Signatur authentifiziert werden, verwenden Sie CBC, andernfalls GCM.

373
Perseids

Eine formale Analyse wurde von Phil Rogaway im Jahr 2011 durchgeführt, hier . Abschnitt 1.6 enthält eine Zusammenfassung, die ich hier transkribiere, wobei ich meine Betonung in Fettdruck anführe (wenn Sie ungeduldig sind, empfiehlt er die Verwendung des CTR-Modus, aber ich schlage vor, dass Sie meine folgenden Absätze über Nachrichtenintegrität und Verschlüsselung lesen).

Beachten Sie, dass die meisten davon eine zufällige IV erfordern, was bedeutet, dass sie nicht vorhersehbar ist und daher mit kryptografischer Sicherheit generiert werden sollte. Einige erfordern jedoch nur ein "Nonce", das diese Eigenschaft nicht erfordert, sondern nur erfordert, dass sie nicht wiederverwendet wird. Daher sind Designs, die auf einer Nonce basieren, weniger fehleranfällig als Designs, die keine Nonce verwenden (und ich glaube, ich habe viele Fälle gesehen, in denen CBC nicht mit der richtigen IV-Auswahl implementiert wird). Sie werden also sehen, dass ich fett geschrieben habe, wenn Rogaway so etwas wie "Vertraulichkeit wird nicht erreicht, wenn die IV eine Nonce ist" sagt. Wenn Sie sich für eine IV entscheiden, die kryptografisch sicher (unvorhersehbar) ist, ist dies kein Problem. Wenn Sie dies nicht tun, verlieren Sie die guten Sicherheitseigenschaften. Verwenden Sie eine IV niemals für einen dieser Modi.

Es ist auch wichtig, den Unterschied zwischen Nachrichtenintegrität und Verschlüsselung zu verstehen. Durch die Verschlüsselung werden Daten ausgeblendet, aber möglicherweise kann ein Angreifer die verschlüsselten Daten ä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 sagt "aber die geänderten Daten werden nach der Entschlüsselung als Müll zurückkommen", wird ein guter Sicherheitsingenieur die Wahrscheinlichkeit feststellen, dass der Müll ein negatives Verhalten in der Software verursacht, und dann wird er diese Analyse in einen echten Angriff verwandeln. Ich habe viele Fälle gesehen, in denen Verschlüsselung verwendet wurde, aber die Nachrichtenintegrität wirklich mehr als die Verschlüsselung benötigt wurde. Verstehe, was du brauchst.

Ich sollte sagen, dass GCM zwar sowohl Verschlüsselung als auch Nachrichtenintegrität aufweist, aber ein sehr fragiles Design ist: Wenn Sie eine IV wiederverwenden, sind Sie fertig - der Angreifer kann Ihren Schlüssel wiederherstellen. Andere Designs sind weniger anfällig, sodass ich persönlich Angst habe, GCM auf der Grundlage der Menge an schlechtem Verschlüsselungscode zu empfehlen, die ich in der Praxis gesehen habe.

Wenn Sie sowohl Nachrichtenintegrität als auch Verschlüsselung benötigen, können Sie zwei Algorithmen kombinieren: In der Regel sehen wir CBC mit HMAC, aber keinen Grund, sich an CBC zu binden. Das Wichtigste, was Sie wissen müssen, ist erst verschlüsseln, dann MAC den verschlüsselten Inhalt , nicht umgekehrt. Außerdem muss die IV Teil der MAC-Berechnung sein.

IP-Probleme sind mir nicht bekannt.

Nun zu den guten Sachen von Professor Rogaway:

Blockieren Sie Verschlüsselungsmodi, aber nicht die Nachrichtenintegrität

ECB: Der Modus verschlüsselt Nachrichten, die ein Vielfaches von n Bits sind, indem jedes n-Bit-Teil separat verschlüsselt wird. Die Sicherheitseigenschaften sind schwach , und die Methode gibt die Gleichheit von Blöcken über beide Blockpositionen und die Zeit hinweg preis. Der Modus ist von beträchtlichem Wert und als Baustein für andere Systeme von großem Wert, erreicht jedoch kein allgemein wünschenswertes Sicherheitsziel und muss mit äußerster Vorsicht verwendet werden. Die EZB sollte nicht als allgemeiner Vertraulichkeitsmodus angesehen werden .

CBC: Ein IV-basiertes Verschlüsselungsschema. Der Modus ist als probabilistisches Verschlüsselungsschema sicher und kann unter der Annahme einer zufälligen IV nicht von zufälligen Bits unterschieden werden. Die Vertraulichkeit wird nicht erreicht, wenn die IV lediglich eine Nonce ist , noch wenn es sich um eine Nonce handelt, die unter demselben Schlüssel verschlüsselt ist, der vom Schema verwendet wird, da der Standard falsch ist schlägt vor zu tun. Chiffretexte sind sehr formbar. Keine ausgewählte Sicherheit für Chiffretext-Angriffe (CCA). Die Vertraulichkeit ist bei Vorhandensein eines Oracle mit korrektem Padding für viele Padding-Methoden nicht mehr gegeben. Die Verschlüsselung ist ineffizient, da sie von Natur aus seriell ist. Die Sicherheitseigenschaften des Modus, die nur für den Datenschutz gelten, sind weit verbreitet und 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 feststellen.

CFB: Ein IV-basiertes Verschlüsselungsschema. Der Modus ist als probabilistisches Verschlüsselungsschema sicher und kann unter der Annahme einer zufälligen IV nicht von zufälligen Bits unterschieden werden. Die Vertraulichkeit wird nicht erreicht, wenn die IV vorhersehbar ist , noch wenn sie von einer Nonce erstellt wird, die unter dem gleichen Schlüssel verschlüsselt ist, der vom Schema verwendet wird, da der Standard falsch ist schlägt vor zu tun. Chiffretexte sind formbar. Keine CCA-Sicherheit. Die Verschlüsselung ist ineffizient, da sie von Natur aus seriell ist. Das Schema hängt von einem Parameter s, 1 ≤ s ≤ n, typischerweise s = 1 oder s = 8 ab. Ineffizient, wenn ein Blockcipher-Aufruf benötigt wird, um nur s Bits zu verarbeiten. Der Modus erzielt eine interessante Eigenschaft der Selbstsynchronisation. Das Einfügen oder Löschen einer beliebigen Anzahl von s-Bit-Zeichen in den Chiffretext stört die korrekte Entschlüsselung nur vorübergehend.

OFB: Ein IV-basiertes Verschlüsselungsschema. Der Modus ist als probabilistisches Verschlüsselungsschema sicher und erreicht eine Ununterscheidbarkeit von zufälligen Bits unter der Annahme einer zufälligen IV. Vertraulichkeit wird nicht erreicht, wenn die IV eine Nonce ist, obwohl eine feste Folge von IVs (z. B. ein Zähler) gut funktioniert. Chiffretexte sind sehr formbar. Keine CCA-Sicherheit. Verschlüsselung und Entschlüsselung sind ineffizient, da sie von Natur aus seriell sind. Verschlüsselt nativ Zeichenfolgen beliebiger Bitlänge (kein Auffüllen erforderlich). Ich kann keine wesentlichen Vorteile gegenüber dem CTR-Modus feststellen.

CTR: Ein IV-basiertes Verschlüsselungsschema, bei dem der Modus eine Unterscheidbarkeit von Zufallsbits unter der Annahme einer Nicht-IV erzielt. Als sicheres, nicht auf CES basierendes Schema kann der Modus auch als probabilistisches Verschlüsselungsschema mit einer zufälligen IV verwendet werden. Vollständige Verletzung der Privatsphäre, wenn eine Nonce beim Ver- oder Entschlüsseln wiederverwendet wird. Aufgrund der Parallelisierbarkeit des Modus ist dieser in einigen Einstellungen häufig schneller als in anderen Vertraulichkeitsmodi. Ein wichtiger Baustein für authentifizierte Verschlüsselungsschemata. Insgesamt ist dies normalerweise der beste und modernste Weg, um eine Verschlüsselung nur für den Datenschutz zu erreichen.

XTS: Bei diesem IV-basierten Verschlüsselungsschema wird für jedes n-Bit eine optimierbare Blockverschlüsselung (sicher als starker PRP) angewendet Stück. Für Nachrichten mit Längen, die nicht durch n teilbar sind, werden die letzten beiden Blöcke speziell behandelt. Der Modus darf nur zum Verschlüsseln von Daten auf einem Speichergerät mit Blockstruktur verwendet werden. Die geringe Breite des zugrunde liegenden PRP und die schlechte Behandlung von fraktionierten Endblöcken sind Probleme. Effizienter, aber weniger wünschenswert als ein (Wide-Block-) PRP-sicherer Blockschlüssel.

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 als VIL-PRFs nachweislich sicher, andere als FIL-PRFs, und einige haben keine nachweisbare Sicherheit. Einige der Systeme lassen schädliche Angriffe zu. Einige Modi sind veraltet. Die Tastentrennung wird für die Modi, die sie haben, nicht ausreichend beachtet. Sollte nicht massenhaft verabschiedet werden, aber es ist möglich, die „besten“ Schemata selektiv auszuwählen. Es wäre auch in Ordnung, keinen dieser Modi zugunsten von CMAC zu übernehmen. Einige der ISO 9797-1-MACs sind weitgehend standardisiert und werden insbesondere im Bankwesen verwendet. Eine überarbeitete Version der Norm (ISO/IEC FDIS 9797-1: 2010) wird in Kürze veröffentlicht [93].

CMAC: Ein MAC, der auf dem CBC-MAC basiert, der Modus ist nachweislich sicher (bis zum Geburtstag gebunden) als (VIL) PRF ( vorausgesetzt, die zugrunde liegende Blockchiffre ist ein guter PRP). Im Wesentlichen minimaler Overhead für ein CBCMAC-basiertes Schema. Ein inhärent serielles Problem in einigen Anwendungsdomänen und die Verwendung mit einer 64-Bit-Blockverschlüsselung würde gelegentliches Neuverschlüsseln erforderlich machen. Sauberer als die MAC-Sammlung nach ISO 9797-1.

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 unterliegt starken nachweisbaren Sicherheitsbeschränkungen, wenn auch nicht aufgrund bevorzugter Annahmen. Mehrere nahe verwandte Varianten in der Literatur erschweren das Verständnis des Bekannten. Es wurden keine schädlichen Angriffe vorgeschlagen. Weitgehend standardisiert und verwendet.

GMAC: Ein nicht-ce-basierter MAC, der ein Sonderfall von GCM ist. Vererbt viele der guten und schlechten Eigenschaften von GCM. Eine Nichtanforderung ist für einen MAC jedoch nicht erforderlich, und hier wird nur ein geringer Nutzen erzielt. Praktische Angriffe, wenn Tags auf ≤ 64 Bit gekürzt werden und der Entschlüsselungsgrad nicht überwacht und eingeschränkt wird. Vollständiger Fehler bei Nicht-Wiederverwendung. Die Verwendung ist ohnehin implizit, wenn GCM übernommen wird. Nicht für separate Standardisierung empfohlen.

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

CCM: Ein nicht-cc-basiertes AEAD-Schema, das die Verschlüsselung im CTR-Modus und den unformatierten CBC-MAC kombiniert. Inhärent seriell, begrenzt die Geschwindigkeit in einigen Kontexten. Nachweislich sicher und mit guten Grenzen, vorausgesetzt, die zugrunde liegende Blockchiffre ist ein guter PRP. Ungnädige Konstruktion, die nachweislich die Arbeit macht. Einfacher zu implementieren als GCM. Kann als nicht-ce-basierter MAC verwendet werden. Weitgehend standardisiert und verwendet.

GCM: Ein nicht-ce-basiertes AEAD-Schema, das die Verschlüsselung im CTR-Modus und eine auf GF (2128) basierende universelle Hash-Funktion kombiniert. Gute Effizienzmerkmale für einige Implementierungsumgebungen. Gute nachweislich sichere Ergebnisse bei minimaler Tag-Kürzung. Angriffe und unzureichende nachweisbare Sicherheitsgrenzen bei starker Tag-Kürzung. Kann als nicht-ce-basierter MAC verwendet werden, der dann als GMAC bezeichnet wird. Fragwürdige Wahl, um andere Nonces als 96-Bit zuzulassen. Es wird empfohlen, Nonces auf 96 Bit und Tags auf mindestens 96 Bit zu beschränken. Weitgehend standardisiert und verwendet.

30
TheGreatContini
  1. Alles andere als die EZB.
  2. Wenn Sie die Klickrate verwenden, müssen Sie für jede Nachricht eine andere IV verwenden. Andernfalls kann der Angreifer zwei Chiffretexte verwenden und einen kombinierten unverschlüsselten Klartext ableiten. Der Grund dafür ist, dass der CTR-Modus eine Blockverschlüsselung im Wesentlichen in eine Streamverschlüsselung umwandelt und die erste Regel für Streamverschlüsselungen lautet, niemals denselben Schlüssel + IV zweimal zu verwenden.
  3. Es gibt wirklich keinen großen Unterschied, wie schwierig die Modi zu implementieren sind. Einige Modi erfordern nur die Blockverschlüsselung, um in der Verschlüsselungsrichtung zu arbeiten. Die meisten Block-Chiffren, einschließlich AES, benötigen jedoch nicht viel mehr Code, um die Entschlüsselung zu implementieren.
  4. Für alle Verschlüsselungsmodi ist es wichtig, unterschiedliche IVs für jede Nachricht zu verwenden, wenn Ihre Nachrichten in den ersten Bytes identisch sein könnten und Sie nicht möchten, dass ein Angreifer dies weiß.
28
Theran

Haben Sie zuerst die Informationen dazu auf Wikipedia gelesen - Block-Chiffrier-Betriebsarten ? Folgen Sie dann dem Referenzlink auf Wikipedia zu NIST: Empfehlung für Block-Chiffrier-Betriebsmodi .

12
KTC

Möglicherweise möchten Sie auswählen, was allgemein verfügbar ist. Ich hatte die gleiche Frage und hier sind die Ergebnisse meiner begrenzten Forschung.

Hardware-Einschränkungen

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Open Source Einschränkungen

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.Zip

11
Mark Lakata