AES256-GCM – Kann jemand erklären, wie man es sicher verwendet (Ruby)?
On Dezember 31, 2020 by adminIch möchte AES256-GCM zum Verschlüsseln einiger Datenbankfelder verwenden. Ich weiß, dass ich für AES256-CBC für jede Verschlüsselung eine neue IV generieren muss, aber ich kann denselben Schlüssel verwenden. Die IV kann offen neben dem Chiffretext gespeichert werden (dh sie kann öffentlich sein).
Ich habe angefangen, über GCM zu lesen, aber ich verstehe einige Dinge nicht ganz. In diesem Stackexchange-Thread heißt es:
- Für GCM ist keine IV erforderlich.
- Das zugeordnete Tag ist nicht erforderlich, kann jedoch die Sicherheit verbessern (Beispiel: Die Verwendung einer Datenbank-ID)
Aber Wikipedia gibt über GCM an :
GCM wurde hat sich im konkreten Sicherheitsmodell als sicher erwiesen. [ 13 ] Es ist sicher, wenn es mit einem Blockverschlüsselungsmodus verwendet wird nicht von einer zufälligen Permutation zu unterscheiden; die Sicherheit hängt jedoch von der Auswahl eines eindeutigen Initialisierungsvektors für jede Verschlüsselung ab, die mit demselben Schlüssel durchgeführt wird (siehe Stream-Verschlüsselungsangriff ).
-
Dies bedeutet, dass die IV immer noch zufällig generiert und für jede Verschlüsselung mit GCM bereitgestellt werden muss. Warum also der Benutzer in Der Stackexchange-Antwortbeitrag besagt, dass wir die IV nicht bereitstellen müssen.
Wikipedia gibt außerdem Folgendes an:
Die Authentifizierungsstärke hängt von ab die Länge des Authentifizierungs-Tags, wie bei allen Authentifizierungscodes für symmetrische Nachrichten. Von der Verwendung kürzerer Authentifizierungs-Tags mit GCM wird jedoch abgeraten. Die mit t bezeichnete Bitlänge des Tags ist ein Sicherheitsparameter. Im Allgemeinen kann es sich um einen der folgenden fünf Werte handeln: 128, 120, 112, 104 oder 96.
-
In OPs Beitrag in diesem Stackexchange-Thread verwendet OP
tag = cipher.auth_tag
. Ist dies standardmäßig 96? Wenn ja, gibt es eine Möglichkeit, dies zu ändern? Gibt es erhebliche Leistungsprobleme bei der Verwendung 128 als 96? -
Funktioniert sowohl das zugeordnete Tag (
cipher.auth_data
) als auch das Authentifizierungs-Tag (cipher.auth_tag
) müssen geheim gehalten werden? Oder können sie offen gehalten werden wie die IV? -
Kann schließlich jemand weiter erklären, was mit dem assoziierten Tag gemeint ist? Beispiel in der Antwort, die im OP-Thread gegeben wurde, war, dass wir eine Datenbank-ID verwenden können, um sicherzustellen, dass die Daten einem bestimmten Datenbankbenutzer gehören. Nehmen wir an, ein Benutzer hat die folgenden Datenbankfelder:
User - primary_id - encrypted_email
Und wir möchten die E-Mail des Benutzers vor dem Einfügen verschlüsseln. Mit Benutzer
primary_id==10
(Ändern des Ruby-Codes von OP):cipher = OpenSSL::Cipher::AES.new(128, :GCM) cipher.encrypt key = cipher.random_key iv = cipher.random_iv cipher.auth_data = "10" # Using DB user"s id! encrypted = cipher.update(data) + cipher.final tag = cipher.auth_tag
Ich habe mit der primären_id des Datenbankbenutzers. Ist das richtig?
Kommentare
- GCM benötigt unbedingt eine IV. Der Kommentar zu diesem Thread lautet, dass ‚ nicht als Teil von
auth_data
enthalten sein muss. - Die
auth_data
ist eine beliebige Kontextinformation (z. B. der Datenbankprimärschlüssel der verschlüsselten Nachricht oder ein Benutzername oder eine Zeichenfolge, die die Aktion auf eine bestimmte Zweck „), der bei der Entschlüsselung wörtlich angegeben werden muss. Es kann öffentlich sein, sollte aber ‚ nicht von der Entität gesteuert werden können, die zu entschlüsselnde Chiffretexte bereitstellt. Dieauth_tag
ist die Ausgabe der Authentifizierungshälfte der Chiffre und wird bei der Entschlüsselung verwendet, um Änderungen an den Schlüssel-, Chiffretext-, IV- oder Authentifizierungsdaten zu erkennen. Es kann neben der verschlüsselten Ausgabe gespeichert werden.
Antwort
Vor der Beantwortung Ihrer Fragen: GCM ist eine authentifizierte Verschlüsselung Die Betriebsart besteht aus zwei separaten Funktionen: einer für die Verschlüsselung (AES-CTR) und einer für die Authentifizierung (GMAC). Es erhält als Eingabe:
- einen Schlüssel
- eine eindeutige IV
- Daten, die nur mit Authentifizierung verarbeitet werden sollen (zugehörige Daten)
- Daten, die durch Verschlüsselung und Authentifizierung verarbeitet werden sollen
Es werden ausgegeben:
- Die verschlüsselten Daten von Eingabe 4
- Ein Authentifizierungs-TAG
Das Authentifizierungs-TAG ist eine Eingabe für die Entschlüsselung. Wenn jemand Ihre zugehörigen Daten oder Ihre verschlüsselten Daten manipuliert, bemerkt die GCM-Entschlüsselung dies und gibt keine Daten aus (oder gibt einen Fehler zurück und Sie sollten die empfangenen Daten verwerfen, ohne sie zu verarbeiten.)
Jetzt:
Dies bedeutet, dass die IV noch zufällig generiert werden muss und warum für jede Verschlüsselung mit GCM bereitgestellt. Warum sagt der Benutzer im StackExchange-Antwortbeitrag, dass wir die IV nicht bereitstellen müssen?
GCM erfordert eine IV. Sie wird sowohl von AES-CTR als auch von AES-GMAC verwendet. Sie benötigen also unabhängig davon, was Sie mit GCM tun eine IV bestehen. Es muss eindeutig und nicht unbedingt zufällig sein. Normalerweise benötigen Implementierungen eine 96-Bit-IV. Dies ist die empfohlene Methode zur Verwendung von GCM gemäß NIST .
In OPs Beitrag in diesem StackExchange-Thread verwendet OP tag = cipher.auth_tag. Ist dies standardmäßig 96? Wenn ja, gibt es einen Weg Gibt es erhebliche Leistungsprobleme bei der Verwendung von 128 als 96?
Standardmäßig ist das Authentifizierungs-Tag 128 Bit. Sie sollten das Authentifizierungs-TAG angeben Für den Empfänger Ihrer Nachricht ist es daher in einigen Anwendungen sinnvoll, ein kleineres Tag zu verwenden. Beachten Sie, dass je kleiner das Tag ist, desto mehr Kollisionen auftreten können. Wenn die Bandbreite kein Problem darstellt, verwenden Sie 128.
Siehe auch den detaillierten Abschnitt zu auth_tag ([tag_len] → string hier
Müssen sowohl das zugeordnete Tag (cipher.auth_data) als auch das Authentifizierungs-Tag (cipher.auth_tag) geheim gehalten werden? Oder können sie wie die IV offen gehalten werden?
Die zugehörigen Daten (Sie haben das zugehörige Tag falsch geschrieben) werden verwendet, damit Daten öffentlich bekannt sind. Beispiel s sind Header oder Zieladressen. Es muss also nicht geheim sein, aber wenn alles verschlüsselt werden muss, setzen Sie die zugehörigen Daten auf „“. Das Authentifizierungs-Tag muss nicht geheim sein und muss dem Empfänger tatsächlich unverschlüsselt zur Verfügung gestellt werden (wie das IV).
Kann jemand schließlich weiter erklären, was mit dem zugeordneten Tag gemeint ist? Das Beispiel in der Antwort, die im Thread von OP gegeben wurde, war dass wir eine Datenbank-ID verwenden können, um sicherzustellen, dass die Daten einem bestimmten Datenbankbenutzer gehören. Angenommen, ein Benutzer verfügt über die folgenden Datenbankfelder:
Es sieht so aus, als würden Sie die Authentifizierungsdaten und das Authentifizierungs-Tag verwechseln. Die Authentifizierungsdaten (oder die zugehörigen) Daten) ist etwas, das Sie durch Authentifizierung schützen möchten (wenn jemand es ändert, wissen Sie es), aber nicht verschlüsselt werden müssen. Wie oben angegeben, ist dies normalerweise bei Headern der Fall, die von Zwischenroutern gelesen werden müssen, die die verschlüsselte Nachricht nicht entschlüsseln können.
Das Authentifizierungs-Tag hängt von den von Ihnen verschlüsselten Daten und den zugehörigen Daten ab Bei der Entschlüsselung müssen Sie auch die zugehörigen Daten verarbeiten, sonst schlagen Sie fehl.
In Ihrem Beispiel, das mir nicht sehr klar ist, authentifizieren Sie die primäre ID und die E-Mail und verschlüsseln die E-Mail. Wenn Sie sowohl die IV als auch die TAG in Ihrer Datenbank speichern, können Sie die E-Mail bei Bedarf entschlüsseln. Ohne ein Authentifizierungs-Tag könnte ein Angreifer die E-Mail von Benutzer1 in die E-Mail von Benutzer2 kopieren, wenn er auch die IVs kopiert, wann Sie dies tun Nach der E-Mail von Benutzer2 suchen Sie werden die E-Mail von Benutzer1 erfolgreich entschlüsseln, ohne etwas zu bemerken.
Wenn Sie stattdessen auch einen TAG verwenden und als zugehörige Daten die ID des entsprechenden Benutzers verarbeiten, kann ein Angreifer dies nicht Führen Sie den vorherigen Angriff durch, da wir bei der Entschlüsselung feststellen werden, dass die zugehörigen Daten vorhanden waren n „t die bei der Verschlüsselung verwendete und der Vorgang schlägt fehl (Sie kennen jemanden, der Benutzer2-Daten manipuliert hat).
Schreibe einen Kommentar