Bedeutet eine größere Anzahl von Hashing-Runden bei der Generierung von aes-128-ctr-Verschlüsselungsschlüsseln eine stärkere Verschlüsselung?

Betrachten Sie das folgende Ethereum-Konto, das ich bei MyEtherWallet erstellt habe :

{ version: 3,
  id: '4447b704-e28c-4e93-8b1d-32f519b46692',
  address: '115312fc0ab77a0fb15a66baf51f58baefcee1dd',
  Crypto: 
   { ciphertext: '299dd3b289bbfa049b42b9e8caff2a37ea9cc0606b33dad64afbb9b8aa5b2bc7',
     cipherparams: { iv: 'ab6abe38032296123b16b029cfce8240' },
     cipher: 'aes-128-ctr',
     kdf: 'scrypt',
     kdfparams: 
      { dklen: 32,
        salt: '2605c6988ea0c68dd8c363e29f815bbabb329a74493abc6766cad31b85b6fa2a',
        n: 1024,
        r: 8,
        p: 1 },
     mac: 'f4425caa02c682c74ffe1ba546ddec1f7e85b573848b896ef1e80f09adbc5511' } }

Der nWert von kdfparamsist 1024. Bei anderen Implementierungen scheint die Anzahl der Hashing-Runden auf 262144(bei keythereum erwähnt ) eingestellt zu sein. Sind diese Parameter weniger sicher? Wenn ja, in welchem ​​Umfang? Wenn nein, warum nicht?

Antworten (1)

Nun, fangen wir an:

Erstens ist AES keine HASHING-Funktion, sondern eine Kryptografiefunktion. Es ist nicht dasselbe, also mischen Sie nicht beides.

Die Anzahl der Runden bedeutet natürlich mehr Sicherheit. Es ist eine grundlegende Verschlüsselung. Je höher die Anzahl der durchgeführten Transformationen, desto weniger anfällig für Entschlüsselungsangriffe und Analysen. Aber mehr Runden bedeuten auch mehr Ausführungszeit und mehr Ressourcen, also müssen Sie einen Mittelwert finden, an dem Sie die Sicherheit und Rechenressourcen optimieren. Für mich scheint 1024 eine faire Zahl zu sein.

In Ihrem Fall ist der schwächste Punkt die IV. Der IV darf niemals ein fester Wert sein, sondern ein zufälliger oder pseudozufälliger Wert, da die Verwendung eines festen IV Ihre Verschlüsselung schwächer und anfälliger für "Kryptoanalyse" -Angriffe macht.

Hoffe meine Antwort wird dir helfen.

FWIW, Der Grund, warum MyEtherWallet eine kleinere Zahl verwendet als, sagen wir, Geth, ist, dass es nicht sinnvoll ist, eine so hohe Zahl im Browser zu verwenden. Beispielsweise dauert das Entschlüsseln eines Schlüsselspeichers von Mist 20-30 Sekunden über Javascript. In Firefox ist dies besonders frustrierend, da es zweimal zu einer Zeitüberschreitung kommt und Sie auf Weiter klicken und auf das Beste hoffen müssen.
Könnten Sie bitte erläutern, warum Sie 1024 für fair halten? Die Standardanzahl der Runden, die Geth verwendet, ist 256-mal größer als die von MEW. Aus meiner Laienperspektive scheint das ziemlich bedeutsam zu sein.
@thoCoStuff Nun, wie Sie sagen, verwendet Geth eine 256-mal größere Anzahl von Runden (262144), während beispielsweise Keythereum nur 65536 verwendet. Da ich ein wenig Kryptographie studiert habe, ist 1024 fair genug für eine faire Sicherheitsoptimierung. Wie ich in meinen Antworten gesagt habe, ist es offensichtlich sicherer, je mehr Runden es gibt, aber meiner Meinung nach (ich meine, ich meine nur eine Meinung, die Mine) sollte 1024 die Sicherheitsmaßnahmen ziemlich fair abdecken. Ich vermute, Sie haben die Anzahl der Runden für eine schnellere Berechnung oder etwas anderes verringert. 1024 wäre also eine schöne Zahl.
In dieser Diskussion wird die "Anzahl der Runden" isoliert betrachtet. Der Wertunterschied könnte auf unterschiedliche KDF (Schlüsselableitungsfunktion) zurückzuführen sein. Unterschiedliche KDFs können mit unterschiedlichen Werten arbeiten. Tatsächlich können unterschiedliche KDFs sogar unterschiedliche Parameter haben. In meiner Parity-Installation ist KDF beispielsweise "pbkdf2", der Parameter für die Anzahl der Runden ist "c" und beträgt 10240. Es gibt auch einen PRF-Parameter, der auf "hmac-sha256" eingestellt ist. Im Fall von OP ist KDF "scrypt", der Parameter für die Anzahl der Runden "n" und es gibt keinen PRF-Parameter, möglicherweise weil das Skript die Logik für die zufällige Generierung hat, sodass kein PRF benötigt wird.