Wie unsicher ist AES-128-CTR, um Daten jeglicher Art mit dem Ethereum-Keystore-Dateiformat zu verschlüsseln?
On November 18, 2020 by adminIch verwende das Ethereum-Keystore-Dateiformat, um andere Daten wie einfachen Text oder JSON zu verschlüsseln.
Hier ist ein Beispiel für Pseudocode der Implementierung:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Mit diesem Code kann ich die Keystore-Datei generieren, die folgendermaßen aussieht:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Dies ist die Standarddatei, in der Millionen von Dollar in Ethers gespeichert sind.
Fragen:
- Ist dies sicher?
- Wenn nicht, warum?
- Wenn ja, ist auch die Verschlüsselung von Klartext oder JSON (kein Hexadezimalformat) sicher?
- Ist sicher, ein kleineres
kdfparams.n
?
Bearbeiten: Um zu verdeutlichen, warum ich dies frage, liegt dies daran, dass eine andere Person dies gesagt hat:
Dies ist überhaupt nicht sicher. Diese Implementierung enthält viele grundlegende Fehler. Ein Beispiel ist die Verwendung eines unsicheren Zufallszahlengenerators, der die Sicherheit der Verschlüsselung vollständig zerstört. Ein anderes Beispiel verwendet AES- 128-CTR ohne Authentifizierung.
Kommentare
- Definieren Sie zunächst “ sicher “ . Aber nach jeder vernünftigen Definition davon mit einem Passwort in derselben Liga wie ‚ 1234 ‚ und Klartext, so groß und redundant, dass nichts verwendbar ist, ist sicher.
- Sicher in Bezug auf sehr, sehr schwer zu brechen, selbst wenn dies der Fall ist ein guter Kryptograph. L. Lassen Sie mich bearbeiten, um zu verdeutlichen, dass dies ein sehr sicheres Kennwort ist.
- Definieren Sie nun “ break “ . Findet das das ursprüngliche Passwort? Erraten Sie den Klartext aus einem Chiffretext? Erraten Sie einen Teil des Klartextes von vielen Chiffretexten, die diesen Teil teilen? Erraten Sie einen Klartext aus vielen Chiffretexten und den ganzen anderen Klartext? Können wir Hilfe von einer ausführbaren Datei erhalten, die auf demselben Computer ausgeführt wird (und wenn ja, welche CPU mit welchem Mikrocode-Patch wird AES-NI verwendet?). Können wir EMI als Seitenkanal verwenden? Ein Keylogger, Hardware oder Sotfare? Was ‚ ist die Implementierung von randomBytes, die einen Einfluss hat?
- Sie können diese Frage nicht beantworten, indem Sie sich den Pseudocode ansehen. Die eigentliche Implementierung kann alle Arten von Schwachstellen und Seitenkanäle enthalten. Sicherheit ist auch keine Binärdatei, sondern ‚ ist eine Frage, wie weit Sie ‚ bereit sind, sich vor immer mehr exotische Angriffe .
- @ fgrieu Entschuldigung, die einzige Frage, die ich beantworten kann, ist: nodejs.org / api / … @EllaRose Ich gehe davon aus, dass die von mir verwendeten Bibliotheken keine Sicherheitslücken aufweisen. Mein obiger Pseudocode ist also nur eine Implementierung dieser Bibliotheksfunktionen, wie beispielsweise randomBytes.
Antwort
Das Schlimmste Eine rein kryptografische Schwäche ist das Passwort (1). Die schlimmsten (und viel schlimmeren) praktischen Schwächen liegen wahrscheinlich in der Implementierung (6) (7) und denjenigen (4) (5), die Kryptographen als nicht verschlüsselt abtun (das einzige erklärte Ziel der Frage).
Kandidaten für Schwachstellen, von kryptografisch (aber noch zu berücksichtigen) bis zur Implementierung:
- Das Passwort: Es ist schwierig, sich ein Passwort mit mehr als 48 Bit Entropie zu merken ( Dies entspricht in etwa einer 16-stelligen Zahl wie 3141592653589793 oder 2718281828459045 und ist mehr als in der obligatorischen XKCD vorgesehen. Bei Verwendung von N = 262144 = 2 18 , r = 1, p = 8 = 2 3 werden mindestens 18 + 3 + 1 = 22 Bits gekauft (siehe this ) im Vergleich zu einem geraden SHA-256-Hash, gefolgt von AES-128, schätze ich ungefähr 32 Bit stärker, daher könnte der Schlüssel ungefähr 80 Bit gut sein, was bedeutet nicht völlig unzerbrechlich durch rohe Gewalt, aber dennoch ziemlich sicher.
- AES-128: Dies hat einen 128-Bit-Schlüssel, der nicht rein kryptoanalytisch bekannt ist Angriff besser als Brute Force und daher viel besser als das Passwort.
- CTR-Modus: Mit dem 128-Bit-Block von AES wäre die einzige Möglichkeit, die Wiederverwendung von Schlüsselströmen zu aktivieren, eine schlechte Zufallszahl Generator für die IV (siehe 6)
- Die Größe des Klartextes kann mühelos aus der Größe des Chiffretextes abgeleitet werden. Dies ist explizit keine theoretische Schwäche der Verschlüsselung, da die Länge wird von dem ausgeschlossen, was eine Chiffre über Klartext verbergen soll. Dies kann jedoch eine praktische Schwäche sein. Sagen wir, die Analyse des Chiffretextes kommt zu dem Schluss, dass dies der Fall ist 17267095423 Oktette; und es gibt irgendwo in der Staatsanwaltschaft eine Akte mit genau dieser Größe, die nachweislich vor der Suche und Beschlagnahme des Chiffretextes liegt und deren bloße Inhaftierung illegal ist.
- Mangelnde Erkennung von (absichtlichen oder zufälligen) Chiffretextänderungen, die einer vorhersehbaren Änderung im Klartext entsprechen: Auch dies ist explizit keine theoretische Schwäche der Verschlüsselung, kann jedoch einige Angriffe zulassen Wenn der Gegner den Chiffretext ändern kann (Beispiel: Wenn der Klartext eine ausführbare Datei oder eine PDF-Datei mit einem bekannten Bruchteil ist, kann dies eine Änderung der Funktionsweise der ausführbaren Datei für irgendetwas oder eine Anzeige der PDF-Datei für irgendetwas ermöglichen). Authentifizierte Verschlüsselung ( AES-GCM ..) löst das.
- Zufallszahlengenerator: Wenn dies schlecht ist oder schlimmer noch mehr oder weniger stecken bleibt (obligatorisch XKCD und Dilbert , die allzu oft zur Realität werden), was in vielen Szenarien die Wiederherstellung von Klartext ermöglichen würde, einschließlich der wiederholten Verschlüsselung verschiedener englischer Text- oder E-Mail-Adressen mit demselben Passwort.
- Ein Seitenkanal, der im Großen und Ganzen ist Sprechen unvorhergesehener oder uneingeschränkter Informationslecks im Implementierungs- oder Nutzungskontext. Es gibt so viele:
- Passwortwiederherstellung vom Passwortinhaber durch Ausnutzen eines Verfahrensfehlers (Passwort auf einem Postit-Hinweis, Master-Passwortliste), Gummischlauch-Kryptoanalyse (obligatorisch XKCD ), rechtliche Varianten (einschließlich der Verwendung von Ausdrücken im Rahmen der Verachtung des Gerichts ), Bestechung, chemische Imprägnierung.
- Wiederherstellung des Passworts durch Schulter-Surfen , Key Logger (Software oder Hardware), Kamera, Mikrofon (eine gute Audioaufnahme von Der Ton der Tasten bei der Eingabe eines Passworts gibt viele Informationen über das Passwort preis, insbesondere wenn er mit der bekannten Tastatureingabe durch denselben Bediener unter denselben Bedingungen korreliert.
- Gerade Kompromittierung des Klartextes, wie auf dem Bildschirm angezeigt (mit TEMPEST -Varianten davon), gedruckt, während sie an einen Drucker übertragen werden oder über ein Netzwerk remote aufgerufen werden, oder nur „vorübergehend“ gespeichert.
- Gerader Kompromiss des Betriebssystems des Mach Wenn Sie eine Verschlüsselung oder Entschlüsselung durchführen (es reicht aus, temporären Root-Zugriff zu erhalten, bedeutet dies, dass der Angreifer in 7.7 ein Spiel hat).
- Kryptoanalytischer Seitenkanal in einiger Entfernung, einschließlich DPA und elektromagnetische Variante DEMA und hypothetisch Timing , wenn auf die Maschine, die die Verschlüsselung / Entschlüsselung durchführt, ein Netzwerk zugreift und nicht AES-Anweisungen .
- Kryptoanalytischer Seitenkanal von einem Prozess, der auf derselben Hardware (einschließlich einer anderen VM) ausgeführt wird, einschließlich cachebasiertem Targeting für AES, wenn AES nicht verwendet wird Anweisungen oder allgemeinere (Meltdown, Spectre), die heutzutage der letzte Schrei sind.
- Ausnutzung verschiedener Softwarefehler; das ist riesig.
Kommentare
- Es wäre nützlicher, wenn ich das Passwort hashe vor der Verschlüsselung? Wie bei der Verwendung von sha oder md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Das Hashing des Passworts vor der Eingabe in scrypt ändert nicht viel an der Schwierigkeit des Angriffs des Passworts ( Punkt 1) Um dies zu verbessern, benötigt man ein besseres Passwort, eine bessere Parametrisierung für die Verschlüsselung oder ein besseres passwortbasiertes Schlüsselableitungsschema (Argon? Balloon?)
Antwort
Das wichtigste Sicherheitselement, das im obigen Schema angegriffen werden kann, ist natürlich die Passphrase. Jetzt ist das Salz wichtig, um Angriffe auf den Regenbogentisch zu vermeiden, aber ansonsten fügt nicht so viel Sicherheit hinzu. Wenn das Salt und das Passwort einigermaßen eindeutig sind, ist auch der Schlüssel eindeutig. In diesem Fall ist die IV nicht so wichtig.
Obwohl die Verwendung eines unsicheren Zufallszahlengenerators schlecht ist, hat sie wahrscheinlich keinen allzu großen Einfluss auf die praktische Sicherheit Dies weist darauf hin, dass tatsächlich schlechte Praktiken implementiert wurden. Was ist, wenn die Passphrase mit demselben unsicheren Zufallsgenerator generiert wurde? Was ist, wenn andere Implementierungsfehler auftreten?
Die Verwendung von nicht authentifiziertem Chiffretext ist eher ein Problem Dies würde es dem Gegner ermöglichen, den Klartext für jedes Bit zu ändern. Der Gegner kann einfach jedes Chiffretext-Bit invertieren, und das Klartext-Bit an derselben Position wird ebenfalls umgedreht. Dies würde bedeuten, dass Sie einen Fehler oder ein Problem bei der Verwendung der Brieftasche erhalten würden. Die Vertraulichkeit des Inhalts der Brieftasche geht wahrscheinlich nicht verloren, aber die Verwendung einer authentifizierten Verschlüsselung ist sicherlich eine bewährte Methode.
Kommentare
- Vielen Dank! Können Sie das erklären? kaum wie man authentifizierten Chiffretext mit diesem Modus erreicht? Ich werde th bearbeiten Die obigen Beispiele, weil ich denke, dass sie mit der ursprünglichen Mac-Eigenschaft zusammenhängen, die ich aus der ursprünglichen Keystore-Datei entfernt habe.
- Der CTR-Modus ist der zugrunde liegende Modus von CCM, GCM, EAX, SIV und einer ganzen Reihe anderer authentifizierter Dateien Chiffren. Eine Kombination des CTR-Modus mit einem (H) MAC kann jedoch durchaus auch sicher sein.Beide erzeugen ein Authentifizierungs-Tag mit ungefähr derselben Größe / Sicherheit. CCM und EAX sind kaum mehr als bestimmte Kombinationen von CTR und MAC, bei denen derselbe Schlüssel für die Verschlüsselung und den MAC verwendet werden kann.
- Beachten Sie, dass ich ‚ ve habe beantwortete diese Frage nach besten Kräften mit allgemeinem Wissen über Chiffren (nicht so sehr Ethereum). Ella Rose hat Recht, dass wir die Sicherheit des Systems nicht aus den Informationen schließen können, die uns in der Frage gegeben wurden. Ich habe mich also ‚ ausschließlich auf die Verwendung von CTR konzentriert.
- Nun, der Zufall scheint sich letztendlich auf den Zufall des Systems zu stützen. Oft sind zufällige Systemquellen relativ sicher und der Begriff CSPRNG wird tatsächlich von der Quelle erwähnt. Die Behauptung, dass es nicht zufällig ist, ist falsch, es sei denn, das System zufällig ist nicht gut implementiert oder gesetzt.
- Es wird nicht empfohlen, einen MAC direkt aus SHA-3 zu erstellen. Stattdessen sollte KMAC verwendet werden (wahrscheinlich) wurde einfach noch nicht ‚ angegeben). Aber ich kann mir keine Situation vorstellen, in der die Verwendung der Verkettung des Schlüssels und des Chiffretextes jemals ein Problem darstellen würde.
Schreibe einen Kommentar