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 jedes Kriteriums.

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

Sehen Sie, was ich unter "Liste der Bewertungskriterien und Anwendbarkeit jedes Kriteriums" verstehe?

Dies hängt nicht wirklich mit der Programmierung zusammen, sondern mit dem Algorithmus.

• 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 eine Verschlüsselung und keine 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 häufigsten, wenn Sie zufällig zugängliche Daten (z. B. eine Festplatte oder einen Arbeitsspeicher) codieren.

• OCB ist bei weitem der beste Modus, da es die Verschlüsselung und Authentifizierung in einem einzigen 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 1 Block verschlüsseln. XTS sollte verwendet werden, wenn Sie Daten mit zufälligem Zugriff und keinen Stream verschlüsseln.

• Sie sollten immer eindeutig verwenden IV ‚s jedes Mal , wenn Sie verschlüsseln und sie sollten zufällig . Wenn Sie nicht garantieren können, dass sie zufällig sind , verwenden Sie OCB, da nur eine Nonce und keine IV erforderlich ist und es einen deutlichen Unterschied gibt. Eine Nonce lässt die Sicherheit nicht fallen, wenn die Leute die nächste erraten können. Eine IV kann dieses Problem verursachen.

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 Standpunkt 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 müssen Sie sich mit diesem lästigen Zustand auf dem Server auseinandersetzen, und wenn Sie irgendwann mehr als einen Server benötigen, 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 bearbeiten kann. Welchen Modus sollten Sie also verwenden? Wenn Sie hierher kommen, lesen Sie die Top-Antwort (entschuldigen Sie, dass Sie myforwik ausgewählt haben). Der erste - EZB - ist nichts für Sie, Sie möchten mehr als einen Block verschlüsseln, der nächste - CBC - klingt gut und Sie brauchen nicht die Parallelität der Klickrate, Sie brauchen keinen Direktzugriff, Also sind keine XTS und Patente eine PITA, also keine 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. Du wählstPKCS7, weil es in einigen ernsthaften 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 sich wohl fühlen, obwohl Sie Ihre sensiblen Daten auf der Clientseite speichern.

Jahre später, nachdem Ihr Service tatsächlich erheblich gewachsen ist, kontaktiert Sie ein IT-Sicherheitsspezialist in einer verantwortungsvollen Offenlegung. Sie sagt dir, dass sie alle deine Cookies mit einem Padding-Orakel-Angriff entschlüsseln kann , weil dein Code eine Fehlerseite erzeugt, wenn das Padding 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 brechen ist.

Was tun, wenn Sie Daten verschlüsseln 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 auf höchster Ebene, die Ihr System für Ihre Aufgabe bietet, und stellen Sie sicher, dass Sie die Garantien verstehen, die es bietet, und vor allem, was es nicht garantiert. Im obigen Beispiel bietet ein Framework wie Play clientseitige Speichermöglichkeiten , macht die gespeicherten Daten jedoch nach einiger Zeit nicht ungültig. Wenn Sie den clientseitigen Status geändert haben, kann ein Angreifer einen vorherigen Status wiederherstellen, ohne dass Sie es bemerken.

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

Wenn Sie aus irgendeinem Grund keine Kryptobibliothek auf hoher Ebene verwenden können, z. B. weil Sie auf eine bestimmte Weise mit dem vorhandenen System interagieren müssen, können Sie sich nicht gründlich weiterbilden. Ich empfehle Cryptography Engineering von Ferguson, Kohno und Schneier zu lesen . Bitte täuschen Sie sich nicht vor, Sie könnten ein sicheres System ohne den erforderlichen Hintergrund aufbauen. Kryptographie 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 des Auffüllens von Orakelangriffen eröffnet. Die einfachste Verteidigung besteht darin, jede Nachricht vor der Entschlüsselung zu authentifizieren. Siehe unten.
  • Die EZB verschlüsselt jeden Datenblock unabhängig und der gleiche Klartextblock führt zum gleichen Chiffretextblock. Sehen Sie sich das mit der EZB verschlüsselte Tux-Bild auf der Wikipedia-Seite der EZB an, um herauszufinden , warum dies ein ernstes Problem darstellt. Ich kenne keinen Anwendungsfall, in dem die EZB akzeptabel wäre.
  • CBC hat eine IV und benötigt daher jedes Mal Zufälligkeit, wenn eine Nachricht verschlüsselt wird. Um einen Teil der Nachricht zu ändern, muss nach der Änderung alles neu verschlüsselt werden. Übertragungsfehler in einem Chiffretextblock zerstören den Klartext vollständig und ändern die Entschlüsselung des nächsten Blocks, die Entschlüsselung kann parallelisiert werden / Verschlüsselung kann 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ängen kann oder nicht. Ähnlich wie bei Stream-Chiffren im Allgemeinen wird der erzeugte Pseudozufallsstrom mit dem Klartext XOR-verknüpft, um den Chiffretext zu erzeugen. Da Sie so viele Bits des Zufallsstroms verwenden können, wie Sie möchten, müssen Sie überhaupt nicht auffüllen. Nachteil dieser Einfachheit ist, dass die Verschlüsselung vollständig formbar istDies bedeutet, dass die Entschlüsselung von einem Angreifer nach Belieben geändert werden kann, wie bei einem Klartext p1, einem Chiffretext c1 und einem Pseudozufallsstrom r, und der Angreifer kann einen Unterschied d so wählen, dass die Entschlüsselung eines Chiffretextes c2 = c1⊕d ist p2 = p1⊕d, 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 worden sein könnte. Alle folgenden Dampfverschlüsselungsmodi erfordern nur die Verschlüsselungsoperation der Blockverschlüsselung. Je nach Verschlüsselung kann dies in extrem beengten Umgebungen Platz (Silizium- oder Maschinencode) sparen.
  • CTR ist einfach, es wird ein Pseudozufallsstrom erzeugt, der unabhängig vom Klartext ist. Verschiedene Pseudozufallsströme werden erhalten, indem von verschiedenen Nonces / IVs hochgezählt wird, die mit einer maximalen Nachrichtenlänge multipliziert werden, so dass eine Überlappung verhindert wird, wobei die Nonces-Nachrichtenverschlüsselung verwendet wird möglich ohne Zufälligkeit pro Nachricht, Entschlüsselung und Verschlüsselung sind parallelisierbar abgeschlossen, Übertragungsfehler wirken sich nur auf die falschen Bits aus und nicht mehr
  • OFB erstellt auch einen Pseudozufallsstrom, der vom Klartext unabhängig ist. Unterschiedliche Pseudozufallsströme werden erhalten, indem für jede Nachricht mit einer anderen Nonce oder Zufalls-IV begonnen wird. Weder Verschlüsselung noch Entschlüsselung sind parallelisierbar, da bei CTR unter Verwendung von Nonces eine Nachrichtenverschlüsselung ohne Nachricht möglich ist Zufälligkeit, wie bei CTR-Übertragungsfehlern, bewirkt nur die falschen Bits und nichts weiter
  • Der Pseudozufallsstrom von CFB hängt vom Klartext ab. Für jede Nachricht wird eine andere Nonce- oder Zufalls-IV benötigt. Wie bei CTR und OFB ist die Verwendung der Nonces-Nachrichtenverschlüsselung ohne Zufälligkeit pro Nachricht möglich, die Entschlüsselung ist parallelisierbar / die Verschlüsselung nicht, Übertragungsfehler vollständig Zerstören Sie den folgenden Block, aber bewirken Sie nur die falschen Bits im aktuellen Block
• Festplattenverschlüsselungsmodi : Diese Modi sind darauf spezialisiert, Daten unterhalb der Dateisystemabstraktion zu verschlüsseln. Aus Effizienzgründen muss zum Ändern einiger Daten auf der Disc nur höchstens ein Disc-Block (512 Byte oder 4 KB) neu geschrieben werden. Sie sind nicht Gegenstand dieser Antwort, da sie ganz andere Verwendungsszenarien haben als die anderen. Verwenden Sie sie nur für die Disc-Verschlüsselung auf Blockebene . Einige Mitglieder: XEX, XTS, LRW.

Authentifizierte Verschlüsselung:

Um das Auffüllen von Orakelangriffen und Änderungen am Chiffretext zu verhindern, kann ein Nachrichtenauthentifizierungscode (MAC) für den Chiffretext berechnet und nur dann entschlüsselt werden, wenn er nicht manipuliert wurde. Dies wird als Encrypt-Then-Mac bezeichnet und sollte jeder anderen Reihenfolge vorgezogen werden . Mit Ausnahme sehr weniger Anwendungsfälle ist Authentizität ebenso wichtig wie Vertraulichkeit (letzteres 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 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. Die Verwendung von zwei Blockverschlüsselungsverschlüsselungen pro Block ist sehr langsam.
• OCB ist schneller, aber durch Patente belastet. Für kostenlose (wie in Freiheit) oder nichtmilitärische Software hat der Patentinhaber jedoch eine kostenlose 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. Die breite Verwendung 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 Bedeutung der Authentifizierung würde ich für die meisten Anwendungsfälle (mit Ausnahme der Festplattenverschlüsselung) die folgenden zwei Blockverschlüsselungsmodi empfehlen: Wenn die Daten durch eine asymmetrische Signatur authentifiziert werden, verwenden Sie CBC, andernfalls verwenden Sie GCM.

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

Beachten Sie, dass für die meisten von diesen die IV zufällig sein muss, was bedeutet, dass sie nicht vorhersehbar ist und daher mit kryptografischer Sicherheit generiert werden sollte. Einige erfordern jedoch nur eine "Nonce", die diese Eigenschaft nicht verlangt, sondern nur erfordert, dass sie nicht wiederverwendet wird. Daher sind Designs, die auf einer Nonce basieren, weniger fehleranfällig als Designs, die dies nicht tun (und glauben Sie mir, ich habe viele Fälle gesehen, in denen CBC nicht mit der richtigen IV-Auswahl implementiert wurde). Sie werden also sehen, dass ich Fettdruck hinzugefügt habe, wenn Rogaway so etwas wie "Vertraulichkeit wird nicht erreicht, wenn die IV eine Nonce ist" sagt. Wenn Sie Ihre IV kryptografisch sicher (unvorhersehbar) auswählen, 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 ein Angreifer kann die verschlüsselten Daten möglicherweise ä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 finden, dass der Müll ein nachteiliges Verhalten in der Software verursacht, und diese Analyse dann 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 fragil, daher habe ich persönlich Angst, GCM aufgrund der Menge an schlechtem Verschlüsselungscode zu empfehlen, die ich in der Praxis gesehen habe.

Wenn Sie beides benötigen, Nachrichtenintegrität und Verschlüsselung, können Sie zwei Algorithmen kombinieren: Normalerweise sehen wir CBC mit HMAC, aber keinen Grund, sich an CBC zu binden. Das Wichtigste, was Sie wissen müssen, ist, zuerst den verschlüsselten Inhalt zu verschlüsseln und dann den verschlüsselten Inhalt zu speichern , 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:

Block-Chiffren-Modi, Verschlüsselung, aber keine Nachrichtenintegrität

EZB : Bei einer Blockverschlüsselung verschlüsselt der Modus Nachrichten, die ein Vielfaches von n Bits sind, indem jedes n-Bit-Stück separat verschlüsselt wird. Die Sicherheitseigenschaften sind schwach , und die Methode leckt die Gleichheit der Blöcke über Blockpositionen und Zeit. Von erheblichem Altwert und von Wert als Baustein für andere Systeme, aber der Modus erreicht selbst kein allgemein wünschenswertes Sicherheitsziel und muss mit erheblicher Vorsicht verwendet werden. Die EZB sollte nicht als "allgemeiner" Vertraulichkeitsmodus angesehen werden .

CBC : Als IV-basiertes Verschlüsselungsschema ist der Modus als probabilistisches Verschlüsselungsschema sicher, wodurch eine Ununterscheidbarkeit von zufälligen Bits unter der Annahme einer zufälligen IV erreicht wird. Vertraulichkeit wird nicht erreicht, wenn die IV lediglich eine Nonce ist oder wenn es sich um eine Nonce handelt, die unter demselben Schlüssel verschlüsselt ist, der vom Schema verwendet wird, wie es der Standard fälschlicherweise vorschlägt. Chiffretexte sind sehr formbar. Keine ausgewählte CCA-Sicherheit (Ciphertext Attack). Die Vertraulichkeit verfällt bei Vorhandensein eines Orakels mit korrekter Polsterung für viele Polsterungsmethoden. Die Verschlüsselung ist ineffizient, da sie von Natur aus seriell ist. Die weit verbreiteten Sicherheitseigenschaften des Modus führen zu häufigem Missbrauch. Kann als Baustein für CBC-MAC-Algorithmen verwendet werden. Ich kann keine wichtigen Vorteile gegenüber dem CTR-Modus feststellen.

CFB : Als IV-basiertes Verschlüsselungsschema ist der Modus als probabilistisches Verschlüsselungsschema sicher, wodurch eine Ununterscheidbarkeit von zufälligen Bits unter der Annahme einer zufälligen IV erreicht wird. Vertraulichkeit wird nicht erreicht, wenn die IV vorhersehbar ist oder wenn sie von einer Nonce erstellt wird, die unter demselben Schlüssel verschlüsselt ist, der vom Schema verwendet wird, wie es der Standard fälschlicherweise vorschlägt. 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 ab, 1 ≤ s ≤ n, typischerweise s = 1 oder s = 8. Ineffizient, da nur ein Blockverschlüsselungsaufruf erforderlich ist, um nur s Bits zu verarbeiten. Der Modus erreicht 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 : Als IV-basiertes Verschlüsselungsschema ist der Modus als probabilistisches Verschlüsselungsschema sicher, wodurch eine Ununterscheidbarkeit von zufälligen Bits unter der Annahme einer zufälligen IV erreicht wird. 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 wichtigen Vorteile gegenüber dem CTR-Modus feststellen.

CTR : Bei diesem IV-basierten Verschlüsselungsschema ist der Modus nicht von zufälligen Bits zu unterscheiden, wenn eine Nonce IV angenommen wird. Als sicheres nichtce-basiertes Schema kann der Modus auch als probabilistisches Verschlüsselungsschema mit einer zufälligen IV verwendet werden. Vollständiger Ausfall der Privatsphäre, wenn eine Nonce bei der Ver- oder Entschlüsselung wiederverwendet wird. Die Parallelisierbarkeit des Modus macht ihn in einigen Einstellungen häufig schneller als in anderen Vertraulichkeitsmodi. Ein wichtiger Baustein für authentifizierte Verschlüsselungsschemata. Insgesamt normalerweise der beste und modernste Weg, um eine reine Datenschutzverschlüsselung zu erreichen.

XTS : Als IV-basiertes Verschlüsselungsschema wendet der Modus eine optimierbare Blockverschlüsselung (sicher als starkes PRP) auf jeden n-Bit-Block an. Für Nachrichten mit Längen, die nicht durch n teilbar sind, werden die letzten beiden Blöcke speziell behandelt. Der Modus kann nur zum Verschlüsseln von Daten auf einem blockstrukturierten Speichergerät 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 eine (Wide-Block-) PRP-sichere Blockverschlüsselung.

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 als VIL-PRFs sicher, andere als FIL-PRFs, und einige haben keine nachweisbare Sicherheit. Einige der Programme lassen schädliche Angriffe zu. Einige der Modi sind veraltet. Die Schlüsseltrennung wird für die Modi, in denen sie vorhanden ist, nicht ausreichend berücksichtigt. Sollte nicht massenhaft angenommen werden, aber die selektive Auswahl der „besten“ Schemata ist möglich. Es wäre auch in Ordnung, keinen dieser Modi zugunsten von CMAC zu verwenden. Einige der ISO 9797-1-MACs sind weitgehend standardisiert und werden insbesondere im Bankwesen eingesetzt. 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 zur Geburtstagsgrenze) als (VIL) PRF (vorausgesetzt, die zugrunde liegende Blockverschlüsselung ist ein guter PRP). Im Wesentlichen minimaler Overhead für ein CBCMAC-basiertes Schema. Inhärent serielle Natur ein Problem in einigen Anwendungsdomänen, und die Verwendung mit einer 64-Bit-Blockverschlüsselung würde gelegentliches erneutes Keying erfordern. Sauberer als die MAC-Sammlung ISO 9797-1.

HMAC : Ein MAC, der eher auf einer kryptografischen Hash-Funktion als auf einer Blockverschlüsselung basiert (obwohl die meisten kryptografischen Hash-Funktionen selbst auf Blockchiffren basieren). Der Mechanismus weist starke nachweisbare Sicherheitsgrenzen auf, wenn auch nicht aufgrund bevorzugter Annahmen. Mehrere eng verwandte Varianten in der Literatur erschweren das Verständnis des Bekannten. Es wurden nie schädliche Angriffe vorgeschlagen. Weitgehend standardisiert und verwendet.

GMAC : Ein nicht auf IC basierender MAC, der ein Sonderfall von GCM ist. Erbt viele der guten und schlechten Eigenschaften von GCM. Für einen MAC ist jedoch keine Nonce-Anforderung erforderlich, und hier bietet er wenig Nutzen. Praktische Angriffe, wenn Tags auf ≤ 64 Bit gekürzt werden und das Ausmaß der Entschlüsselung nicht überwacht und eingeschränkt wird. Vollständiger Fehler bei Nicht-Wiederverwendung. Die Verwendung ist ohnehin implizit, wenn GCM angewendet wird. Nicht für eine separate Standardisierung empfohlen.

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

CCM : Ein nichtce-basiertes AEAD-Schema, das die CTR-Modusverschlüsselung und den rohen CBC-MAC kombiniert. Inhärent seriell, Geschwindigkeitsbegrenzung in einigen Kontexten. Voraussichtlich sicher und mit guten Grenzen, vorausgesetzt, die zugrunde liegende Blockverschlüsselung ist ein gutes PRP. Unglaubliche Konstruktion, die nachweislich den Job macht. Einfacher zu implementieren als GCM. Kann als nichtce-basierter MAC verwendet werden. Weitgehend standardisiert und verwendet.

GCM : Ein nichtce-basiertes AEAD-Schema, das CTR-Modus-Verschlüsselung und eine GF (2128) -basierte universelle Hash-Funktion kombiniert. Gute Effizienzmerkmale für einige Implementierungsumgebungen. Gute, nachweislich sichere Ergebnisse bei minimaler Tag-Kürzung. Angriffe und schlechte nachweisbare Sicherheitsgrenzen bei erheblicher Kürzung von Tags. Kann als nichtce-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.

1. Alles andere als EZB.
2. Wenn Sie CTR verwenden, müssen Sie für jede Nachricht unbedingt 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 Stream-Verschlüsselung umwandelt und die erste Regel für Stream-Verschlüsselungen darin besteht, niemals denselben Schlüssel + IV zweimal zu verwenden.
3. Es gibt wirklich keinen großen Unterschied, wie schwierig die Implementierung der Modi ist. In einigen Modi muss die Blockverschlüsselung nur in Verschlüsselungsrichtung arbeiten. Die meisten Blockchiffren, 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, für jede Nachricht unterschiedliche IVs zu verwenden, wenn Ihre Nachrichten in den ersten mehreren Bytes identisch sein könnten und Sie nicht möchten, dass ein Angreifer dies weiß.

Haben Sie zunächst die Informationen dazu auf Wikipedia - Block Chiffre-Betriebsarten gelesen ? Folgen Sie dann dem Referenzlink auf Wikipedia zu NIST: Empfehlung für Block Cipher-Betriebsmodi .

Möglicherweise möchten Sie basierend auf dem, was allgemein verfügbar ist, eine Auswahl treffen. Ich hatte die gleiche Frage und hier sind die Ergebnisse meiner begrenzten Forschung.

Hardwareeinschrä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

Ich kenne einen Aspekt: ​​Obwohl CBC durch Ändern der IV für jeden Block eine bessere Sicherheit bietet, gilt dies nicht für verschlüsselte Inhalte mit zufälligem Zugriff (wie eine verschlüsselte Festplatte).

Verwenden Sie daher CBC (und die anderen sequentiellen Modi) für sequentielle Streams und EZB für den wahlfreien Zugriff.