Gibt es irgendwelche Sicherheitsnachteile beim Verschlüsseln eines bestimmten Schlüssels mit sich selbst unter Verwendung von AES im CBC-Modus und unter Verwendung einer IV (natürlich)?
Die Grundsätze werden eingehalten: Der Schlüssel ist geheim, und der IV ist öffentlich (da dies die Sicherheit der Verschlüsselung nicht beeinträchtigt).
Ein potentieller Angreifer weiß jedoch (da er auf den Quellcode zugreifen kann), dass die Zeichenfolge verschlüsselt ist, indem er sich selbst als Schlüssel verwendet.
Mein Urteil sieht keine Probleme, aber ich versuche es sicherzustellen.
Danke.
EDIT - Details der Aufgabe, ich hoffe, ich werde sie klar vermitteln können, es ist mir noch nicht ganz klar:
Mein System verwendet eine Verschlüsselung, um bestimmte Werte in MySQL-Tabellen zu speichern. Die Verschlüsselung wird mit dem PHP-Code durchgeführt (nicht mit dem in MySQL integrierten AES). Offensichtlich brauche ich einen geheimen Schlüssel, der nur einmal beim System-Setup vom Systemadministrator eingerichtet werden muss. Dies ist wichtig, da das Ändern des Schlüssels nach dem Speichern von verschlüsselten Daten die Daten entschlüsselt.
Der Administrator kann einen geheimen Schlüssel einrichten, indem er einfach eine PHP-Skriptdatei über FTP (oder was auch immer) bearbeitet. Aber das ist nicht was ich will.
Ich möchte ein Installations-Skript haben, bei dem der Administrator den geheimen Schlüssel auswählt, der mit sich selbst verschlüsselt und in einer Tabelle gespeichert wird. Zugegeben, ein wichtiger Punkt, der unten gemacht wurde, ist, dass Sie den Schlüssel benötigen würden, um den Schlüssel zu entschlüsseln ... Ich kam nicht so weit in meiner Argumentation, ich war gerade dabei, zu untersuchen, ob ein Schlüssel mit sich selbst verschlüsselt ist als Schlüssel ist immer noch eine sichere Sache.
Wenn Sie irgendwelche Ideen bezüglich des oben genannten haben, wird es sehr geschätzt.
Danke.
Die Verschlüsselung des Schlüssels mit sich selbst ist im Grunde eine Ad-hoc-Hash-Funktion. Sie könnten also stattdessen einen echten verwenden.
Wie Sie in Ihrem Kommentar in Jespers Antwort erwähnt haben, "liegt die Stärke im Verschlüsselungsschlüssel" und im Verschlüsselungsalgorithmus. Wenn beide stark sind, sollte es sicher sein. Soweit ich weiß, ist die technische Schwachstelle einer starken Verschlüsselung und eines Schlüssels in der Implementierung, falls vorhanden.
Interessiert zu wissen, für welche Anwendung Sie diese Methode verwenden werden, wenn Sie es sagen können.
Bearbeiten Dies beantwortet nicht genau die Frage im Titel des Posts, aber ich denke, es ist relevant für Ihren aktualisierten Beitrag:
Annahme eines starken und korrekt implementierten AES mit CBC und IV, und dass der Angreifer auf die Tabelle zugreifen kann, in der Sie den verschlüsselten Hauptschlüssel speichern.
Es sollte nur ein geringer Sicherheitsunterschied bestehen, ob Sie einen verschlüsselten Hauptschlüssel mit sich selbst speichern oder den kryptografischen Hash des Hauptschlüssels speichern. Unter der Annahme, dass sowohl der kryptografische Hash als auch AES im CBC-Modus gleich sicher sind, liegt die Stärke in der Stärke des Hauptschlüssels.
Wenn der Hauptschlüssel schwach ist, kann er, selbst wenn ein Angreifer den Hauptschlüssel nicht aus dem kryptographischen Hash des Hauptschlüssels erhalten kann, den Hauptschlüssel und damit die "bestimmten Werte" über die "bestimmten Werte" erhalten " Tabelle. Wenn ein Hauptschlüssel verwendet wird, um sich selbst zu verschlüsseln, kann er den Hauptschlüssel über die Tabelle "bestimmte Werte" oder die Hauptschlüsseltabelle erhalten.
Unabhängig davon, ob Sie die Chiffre zum Verschlüsseln und Speichern des Hauptschlüssels oder zum kryptografischen Hash verwenden und den Hauptschlüssel speichern, stellen Sie sicher, dass der Hauptschlüssel stark ist. Es scheint, als ob du ein Open-Source-System schreibst. Mein Vorschlag ist, dass Ihr System jeden möglichen Hauptschlüssel gegen einen regulären Ausdruck (oder eine Funktion) prüft und diesen Schlüssel ablehnt, wenn er als nicht stark genug erachtet wird.
Ich hoffe, ich habe Ihren Beitrag auch richtig verstanden.
Disclaimer: Ich bin kein Sicherheitsexperte und auch nicht in der Sicherheitsindustrie.
Erstens: Nicht wirklich Sicherheitsexperte
Um dies jetzt zu erreichen, möchten Sie einen geheimen Wert speichern und nur den geheimen Wert erhalten, aber den geheimen Wert angeben? :)
Aber ich kann sehen, wohin Sie damit gehen wollen, für ein Passwort-System (vielleicht), Sie können sie dann einfach zusammen validieren.
Einige Nachteile können sein, dass wenn der Hacker Zugriff auf alle Benutzerpasswörter hat und der Hacker ein Konto mit einem Passwort hat, an das er sich erinnern kann, dann kann er sehr leicht Ihre Verschlüsselungslogik erkennen. Er kann danach einen Wörterbuchangriff machen und viele Passwörter bekommen. Dazu würde ich zumindest einen eindeutigen Hash für jeden Datensatz in Betracht ziehen. Dann kann er immer noch Wörterbuch angreifen, aber es wird viel länger dauern. Fügen Sie dann auch einen benutzerdefinierten Hash hinzu, der tief in Ihrer Anwendung gespeichert ist, also muss er dies auch erraten oder Zugriff auf den Anwendungscode haben.
Also ich würde zumindest einen Schlüssel empfehlen, der eine Kombination aus Passwort + record_hash + shared_hash
istUPDATE: Ich kann sehen, dass der Hacker Zugriff auf Code hat, und versuche dann, shared_hash an einem Ort zu speichern, auf den er nicht zugreifen kann.
Tags und Links encryption