¿Una mayor cantidad de rondas de hashing en la generación de claves de cifrado aes-128-ctr significa un cifrado más fuerte?

Considere la siguiente cuenta de Ethereum que creé en MyEtherWallet :

{ 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' } }

El nvalor de kdfparamses 1024. Otras implementaciones parecen tener el número de rondas de hashing establecido en 262144(mencionado en keythereum ). ¿Son estos parámetros menos seguros? Si es así, ¿en qué medida? ¿Si no, porque no?

Respuestas (1)

Bueno, comencemos:

Primero, AES no es una función HASHING, sino una función criptográfica. No es lo mismo, así que no mezcles ambos.

El número de rondas significa, obviamente, más seguridad. Es un cifrado básico. Cuanto mayor sea el número de transformaciones realizadas, menos vulnerable a los ataques de descifrado y análisis. Pero más rondas significa también más tiempo de ejecución y recursos, por lo que debe encontrar un punto medio en el que optimice la seguridad y los recursos de cómputo. Para mí, 1024 parece un número justo.

En tu caso, el punto más débil es el IV. El IV nunca será un valor fijo, sino aleatorio o pseudoaleatorio, debido a que el uso de un IV fijo hace que su encriptación sea más débil y más vulnerable a los ataques de "criptoanálisis".

Espero que mi respuesta te ayude.

FWIW, la razón por la que MyEtherWallet usa un número más pequeño que, digamos, geth, es que no es razonable usar un número tan alto en el navegador. Por ejemplo, descifrar un almacén de claves de Mist lleva entre 20 y 30 segundos a través de Javascript. En Firefox, esto es especialmente frustrante ya que se agota el tiempo dos veces y debes presionar continuar y esperar lo mejor.
¿Podría explicar por qué considera que la 1024 es justa? El número predeterminado de rondas que usa Geth es 256 veces mayor que MEW. Desde mi perspectiva laica, eso parece bastante significativo.
@thoCoStuff Bueno, como dices, geth usa 256 veces más rondas (262144) mientras que, por ejemplo, keythereum usa solo 65536. Como he estudiado un poco de criptografía, 1024 es lo suficientemente justo para una optimización de seguridad justa. Como dije en mis respuestas, obviamente es más seguro cuanto mayor sea la cantidad de rondas, pero en mi opinión (quiero decir, solo una opinión, la mía) 1024 cubrirá las medidas de seguridad de manera bastante justa. Supongo que ha reducido el número de rondas para un cálculo más rápido, o algo más. Así que 1024 sería un buen número.
En esta discusión, el "número de rondas" se considera de forma aislada. La diferencia de valor podría deberse a diferentes KDF (función de derivación de clave). Diferentes KDF pueden funcionar con diferentes valores. De hecho, diferentes KDF pueden incluso tener diferentes parámetros. Por ejemplo, en mi instalación de Parity, KDF es "pbkdf2", el parámetro de número de rondas es "c" y es 10240. También hay un parámetro PRF, establecido en "hmac-sha256". En el caso de OP, KDF es "scrypt", el parámetro de número de rondas es "n", y no hay un parámetro PRF, tal vez porque el script tiene la lógica para la generación aleatoria, por lo que no se necesita un PRF.