¿Qué tan inseguro es AES-128-CTR para cifrar cualquier tipo de datos utilizando el formato de archivo de almacén de claves Ethereum?
On noviembre 18, 2020 by adminEstoy usando el formato de archivo del almacén de claves Ethereum para cifrar cualquier otro dato, como texto plano o JSON.
Aquí hay un ejemplo de pseudocódigo de la implementación:
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)
Con este código puedo generar el archivo de almacén de claves que se ve así:
{ "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" } }
Este es el archivo estándar que almacena millones de dólares de personas en Ethers.
Preguntas:
- ¿Es seguro?
- Si no es así, ¿por qué?
- En caso afirmativo, ¿también es seguro cifrar texto plano o JSON (sin formato hexadecimal)?
- Es seguro establecer un
kdfparams.n
?
Editar: Para aclarar por qué estoy preguntando esto es porque otra persona dijo esto:
Esto no es seguro en absoluto. Esta implementación contiene muchos errores básicos. Un ejemplo es el uso de un generador de números aleatorios inseguro, que destruye por completo la seguridad del cifrado. Otro es el uso de AES- 128-CTR sin autenticación.
Comentarios
- Primero, defina » secure » . Pero según cualquier definición razonable de eso, con una contraseña en la misma liga que ‘ 1234 ‘, y texto sin formato tan grande y redundante, nada utilizable es seguro.
- Seguro en términos de muy, muy difícil de romper incluso si es un buen criptógrafo. L déjeme editar para aclarar que sería una contraseña muy segura.
- Ahora, defina » break » . ¿Es encontrar la contraseña original? ¿Adivinando el texto sin formato de un texto cifrado? ¿Adivinando algo del texto plano de muchos textos cifrados que comparten algunos? ¿Adivinar un texto sin formato de muchos textos cifrados y todos los demás textos sin formato? ¿Podemos obtener ayuda de un ejecutable que se ejecuta en la misma máquina (y si es así, exactamente qué CPU con qué parche de microcódigo? ¿Se usa AES-NI?). ¿Podemos usar EMI como canal lateral? ¿Un keylogger, hardware o sotfare? De hecho, ¿qué ‘ es la implementación de randomBytes, que tiene influencia?
- No puedes responder esta pregunta mirando psuedocode. La implementación real puede contener todo tipo de vulnerabilidades y canales laterales . La seguridad tampoco es un binario, es ‘ una cuestión de hasta dónde ‘ estás dispuesto a llegar para protegerte contra cada vez más ataques exóticos .
- @ fgrieu lo siento, la única pregunta que puedo responder es: nodejs.org / api / … @EllaRose Supongo que las bibliotecas que estoy usando no tienen vulnerabilidades. Entonces, mi pseudocódigo anterior es solo una implementación de esas funciones de bibliotecas, como randomBytes.
Respuesta
Lo peor La debilidad puramente criptográfica es la contraseña (1). Es probable que las peores (y mucho peores) debilidades prácticas estén en la implementación (6) (7), y aquellas (4) (5) que los criptógrafos descartan como fuera del alcance del cifrado (el único objetivo declarado de la pregunta).
Candidatos para debilidades, desde criptográfico (pero aún por considerar) hasta implementación:
- La contraseña: es difícil recordar una contraseña con más de 48 bits de entropía ( eso es aproximadamente equivalente a un número de 16 dígitos, como 3141592653589793 o 2718281828459045, y más de lo previsto por el XKCD obligatorio). Usando N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , compra al menos 18 + 3 + 1 = 22 bits (ver this ) en comparación con un hash SHA-256 simple seguido de AES-128, supongo que unos 32 bits más fuerte, por lo que la clave podría ser buena en unos 80 bits, lo que es no del todo irrompible por fuerza bruta pero sigue siendo bastante seguro.
- AES-128: tiene una clave de 128 bits, no se conoce que sea puramente criptoanalítica ataque mejor que la fuerza bruta, y por lo tanto es mucho mejor que la contraseña.
- Modo CTR: con el bloque de 128 bits de AES, la única forma en que la reutilización de la secuencia de claves podría entrar en funcionamiento sería un número aleatorio incorrecto generador para el IV (ver 6)
- El tamaño del texto sin formato se puede deducir sin esfuerzo del tamaño del texto cifrado. Esto es explícitamente no una debilidad teórica del cifrado, ya que la longitud está excluido de lo que se supone que oculta un cifrado sobre el texto plano. Sin embargo, eso puede ser una debilidad práctica. Digamos que el análisis del texto cifrado concluye que es 17267095423 octetos; y existe, en algún lugar de la acusación, un archivo con exactamente ese tamaño, demostrablemente anterior al registro e incautación del texto cifrado, y cuya mera detención es ilegal.
- Falta de detección de alteraciones (intencionales o accidentales) del texto cifrado, correspondientes a una alteración predecible en el texto sin formato: de nuevo, esto es explícitamente no una debilidad teórica del cifrado, pero puede permitir algunos ataques si el adversario puede alterar el texto cifrado (ejemplo: si el texto sin formato es un ejecutable o PDF con una fracción conocida, eso puede permitir cambiar lo que hace el ejecutable con respecto a cualquier cosa, o hacer que el PDF se muestre como cualquier cosa). El cifrado autenticado ( AES-GCM ..) resuelve eso.
- Generador de números aleatorios: si esto es malo o peor se atasca más o menos (obligatorio XKCD y Dilbert que se vuelven realidad con demasiada frecuencia), eso permitiría recuperar texto sin formato en muchos escenarios, incluido el cifrado repetido de diferentes direcciones de correo electrónico o texto en inglés con la misma contraseña.
- Un canal lateral, es decir, en términos generales Hablando de filtraciones de información imprevistas o no mitigadas en el contexto de implementación o uso. Hay tantos:
- Recuperación de la contraseña del titular de la contraseña mediante la explotación de un error de procedimiento (contraseña en una nota posterior, lista de contraseñas maestras), criptoanálisis de manguera de goma (obligatorio XKCD ), variantes legales (que implican el uso de expresiones del tipo desacato al tribunal ), soborno, impregnación química ..
- Recuperación de contraseña por navegación de hombro , registrador de teclas (software o hardware), cámara, micrófono (una buena captura de audio de el sonido de las teclas al ingresar una contraseña filtra mucha información sobre la contraseña, especialmente cuando se correlaciona con la entrada de teclado conocida por el mismo operador en las mismas condiciones).
- Compromiso directo de texto plano como se muestra en la pantalla (con TEMPEST variantes de eso), impresas, mientras se transmiten a una impresora o se accede de forma remota por una red, o simplemente se almacenan «temporalmente».
- Compromiso directo del sistema operativo de la máquina ine haciendo encriptación o desencriptación (obtener acceso temporal de root es suficiente, significa que en 7.7 es un juego para el atacante).
- Canal lateral criptoanalítico a distancia, incluyendo DPA y la variante electromagnética DEMA, e hipotéticamente sincronización si la máquina que realiza el cifrado / descifrado es accedida por una red y no utiliza Instrucciones de AES .
- Canal lateral criptoanalítico de un proceso que se ejecuta en el mismo hardware (incluida otra VM), incluida la orientación basada en caché para AES cuando no se usa AES instrucciones, o más generales (Meltdown, Spectre) que están de moda en estos días.
- Explotación de varios errores de software; eso es enorme.
Comentarios
- Sería más útil si escribiera la contraseña antes de la encriptación? ¿Como usar sha o md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Hashing de la contraseña antes de ingresar en scrypt no cambia mucho la dificultad de ataque de la contraseña ( punto 1). Para mejorar eso, se necesita una mejor contraseña, una mejor parametrización de scrypt o un mejor esquema de derivación de claves basado en contraseña (¿Argon? ¿Globo?)
Respuesta
El principal elemento de seguridad que puede ser atacado en el esquema anterior es, por supuesto, la frase de contraseña. Ahora la sal es importante para evitar ataques de tabla de arco iris, pero de lo contrario no agrega tanta seguridad. Si la sal y la contraseña son razonablemente únicas, la clave también es única. En ese caso, el IV no es tan importante.
Entonces, aunque usar un generador de números aleatorios inseguro es malo, probablemente no tendrá tanta influencia en la seguridad práctica. , indica que efectivamente se implementaron malas prácticas. ¿Qué pasa si la frase de contraseña se generó usando ese mismo generador aleatorio inseguro? ¿Qué pasa si surgen otros errores de implementación?
Usar texto cifrado no autenticado es un problema mayor, ya que le permitiría al adversario cambiar el texto sin formato para cada bit. El adversario simplemente puede invertir cualquier bit de texto cifrado y el bit de texto sin formato en la misma posición también se invertirá. Esto significaría que obtendría un error o un problema al usar la billetera. Es probable que no se pierda la confidencialidad del contenido de la billetera, pero el uso de cifrado autenticado es sin duda la mejor práctica.
Comentarios
- ¡Gracias! ¿Podría explicarnos? apenas cómo lograr un texto cifrado autenticado con este modo? Voy a editar el Los ejemplos anteriores porque creo que está relacionado con la propiedad mac original que eliminé del archivo de almacén de claves original.
- El modo CTR es el modo subyacente de CCM, GCM, EAX, SIV y un montón de otros autenticados cifrados. Sin embargo, una combinación del modo CTR con un (H) MAC ciertamente también puede ser segura.Ambos producen una etiqueta de autenticación con aproximadamente el mismo tamaño / seguridad. CCM y EAX son poco más que combinaciones específicas de CTR y MAC donde se puede usar la misma clave para el cifrado y MAC.
- Tenga en cuenta que ‘ ve Respondí esta pregunta lo mejor que pude, utilizando conocimientos genéricos de cifrados (no tanto Ethereum). Ella Rose tiene razón en que no podemos concluir la seguridad del sistema a partir de la información que se nos proporciona en la pregunta. Así que ‘ me he centrado únicamente en el uso de CTR.
- Bueno, el azar parece depender, al final, del sistema aleatorio. A menudo, las fuentes aleatorias del sistema son relativamente seguras y, de hecho, la fuente menciona el término CSPRNG. Por lo tanto, la afirmación de que no es aleatorio es incorrecta, a menos que el sistema aleatorio no esté bien implementado o sembrado.
- No se recomienda crear un MAC desde SHA-3 directamente, se debería haber usado KMAC en su lugar (probablemente simplemente no estaba ‘ t especificado todavía en ese momento). Pero no puedo pensar en ninguna situación en la que el uso sobre la concatenación de la clave y el texto cifrado suponga un problema.
Deja una respuesta