El impacto de la computación cuántica de Google en la seguridad de Ethereum

Autor: Comunidad de Denglian

Enlace al artículo original:

Declaración: Este artículo es una reproducción, los lectores pueden obtener más información a través del enlace original. Si el autor tiene alguna objeción respecto a la forma de reproducción, por favor contáctenos, haremos las modificaciones según las solicitudes del autor. La reproducción se realiza únicamente para compartir información, no constituye ningún consejo de inversión, ni refleja las opiniones y posiciones de Wu.

Aunque la computación cuántica todavía tiene un fuerte carácter de especulación, con la mejora en la eficiencia del algoritmo de Shor, la seguridad de las cuentas de Ethereum, los mecanismos de consenso y los sistemas de prueba de Layer 2 enfrentan riesgos a largo plazo. Al migrar hacia el estándar post-cuántico del NIST, se deben prevenir posibles puertas traseras criptográficas.

Contexto (Contexto)

Investigadores de Google, Berkeley, Stanford y la Fundación Ethereum publicaron un artículo sobre la optimización sustancial de algoritmos cuánticos y su impacto en las criptomonedas.

Aquí algunos antecedentes necesarios: la computación cuántica en gran medida es una exageración. Se obtiene atención mediante la especulación y la inversión, y por ello recibe financiamiento continuo.

Esto no significa que no sea una optimización sustancial —lo es— pero al leer sobre análisis criptográficos cuánticos, debemos ser conscientes de este contexto. Tenemos tiempo para clasificar y iterar, y considerando la historia que involucra a la NSA y al NIST, primero debemos ser escépticos respecto a las recomendaciones del NIST sobre las redes de reticulados (Lattice).

¿De qué estamos hablando? (De qué tratamos)

El artículo se centra en Bitcoin (probablemente por sospechas sobre SECP256R1/P256) y en la curva SECP256K1 (K256), que usan muchas otras cadenas. En nuestro análisis, nos enfocaremos en la red de Ethereum, ya que Monero usa curvas diferentes, y en este contexto específico, Bitcoin no ofrece privacidad ni programabilidad.

Curva Monero (ed25519) no ha sido claramente objetivo, aunque el artículo menciona que romperla podría no ser mucho más difícil que K256.

Bajo algoritmos de búsqueda cuántica, encontrar pre-imágenes de hashes como SHA256 o KECCAK256 realmente tendrá una ligera aceleración, pero esta no es exponencial. No representa una amenaza razonable para estos algoritmos hash, y el artículo no propone mejoras en los algoritmos para atacarlos.

Cronograma (Líneas de tiempo)

El NIST generalmente se encarga de los estándares criptográficos y anuncios de seguridad del gobierno de EE. UU. El informe interno 8547, publicado en noviembre de 2024, marca que: los protocolos de intercambio de claves y firmas basados en RSA y logaritmos discretos en curvas elípticas serán descontinuados antes de 2030 y prohibidos antes de 2035. Esto se debe a que el algoritmo de Shor puede acelerar exponencialmente la resolución de estos problemas.

El artículo demuestra una optimización que puede reducir significativamente la cantidad de qubits lógicos y puertas Toffoli necesarias para atacar K256. Recomienda abandonar estos sistemas cuanto antes, aunque no da fechas específicas.

Aunque no modela otras curvas como BN254 o BLS12-381, menciona que la dificultad de atacarlas no debería ser mucho mayor que K256. Esto hace que los emparejamientos bilineales sean generalmente más vulnerables y puedan permitir recuperar sistemas de compromiso polinomial (como los usados en zk-SNARKs, por ejemplo, KZG) con “residuos tóxicos (toxic waste)”.

Riesgos para Ethereum (Riesgos para Ethereum)

El artículo identifica cinco tipos de vulnerabilidades en Ethereum:

Cuenta (Cuenta)

Gestión (Administración)

Código (Código)

Consenso (Consenso)

Disponibilidad de datos (Disponibilidad de datos)

Cuentas y gestión (Cuentas y Administración)

Dado que las direcciones de las cuentas son hashes truncados de claves públicas K256, las cuentas que no hayan enviado transacciones ni publicado firmas (como firmas permitidas) no expondrán su clave pública. Esto significa que actualmente no están en riesgo.

Sin embargo, una vez que una cuenta publique una firma, su clave pública puede ser recuperada, exponiéndola a ataques.

La vulnerabilidad de “gestión” se refiere a fallos en las cuentas con privilegios. Las cuentas con múltiples firmas M de N necesitan que M cuentas sean comprometidas, pero en otros aspectos no tienen protección. Esto implica que los contratos configurables pueden ser manipulados, y los contratos inteligentes de proxy actualizables pueden ser reemplazados por contratos de drenaje (drainer) para robar tokens.

Código (Código)

Esta vulnerabilidad se refiere a contratos que dependen de precompilados que usan primitivas criptográficas no resistentes a ataques cuánticos. Actualmente, estos incluyen:

ECDSA K256

ECDSA P256

Prueba de compromiso polinomial KZG

Operaciones de puntos y emparejamientos bilineales BN254

Operaciones de puntos y emparejamientos bilineales BLS12-381

El precompilado ECDSA P256 extiende el problema de las cuentas a firmas en cuentas inteligentes que usan la curva P256, como las que se autentican con firmas en enclaves seguros de iOS y Android (Face ID, huellas).

Las curvas BN254 y BLS se usan en protocolos de privacidad y en zk-SNARKs en Layer 2. Recuperar “residuos tóxicos (toxic waste)” de estos sistemas permitiría a atacantes falsificar pruebas en cualquier sistema que dependa de estos compromisos.

Consenso (Consenso)

Ethereum usa BLS12-381 para agregación de firmas en su mecanismo de consenso. La gravedad depende del porcentaje de la red afectada:

Atacar a los validadores: puede forzar penalizaciones de participación (slash).

Atacar a más de 1/3: puede impedir la finalización (finalidad).

Atacar a más de 1/2: puede afectar la selección de bifurcaciones y forzar reorganizaciones profundas (reorganización).

Atacar a más de 2/3: sería catastrófico; requeriría recuperación fuera de la red.

Disponibilidad de datos (Disponibilidad de datos)

El sistema Blob de Ethereum usa muestras de disponibilidad de datos con compromisos KZG. Si se recuperan residuos tóxicos en la configuración, se puede crear una prueba falsa de disponibilidad de datos, lo que afectaría a Layer 2 que dependa del almacenamiento de blobs para la transformación de estado.

El problema post-cuántico (El problema post-cuántico)

La solución directa es migrar a sistemas basados en reticulados (Lattice) o hash. El NIST ha establecido los siguientes estándares:

(FIPS 203): mecanismo de empaquetamiento de claves basado en reticulados modulares

(FIPS 204): firma digital basada en reticulados modulares

(FIPS 205): firma digital sin estado basada en hash

Sin embargo, debido a la intervención de la NSA, los estándares del NIST siempre han sido cuestionados. Casos históricos incluyen el descifrador DES de la EFF, puertas traseras en Dual EC DRBG por la NSA, y la falta de transparencia del NIST en la criptografía post-cuántica relacionada con la NSA.

Expertos reconocidos como D.J. Bernstein han destacado la gran superficie de ataque de la criptografía basada en reticulados (Lattice), y el hecho de que estas implementaciones siguen evolucionando frente a nuevos vectores de ataque.

Conclusiones (Resumen)

Todavía tenemos unos años. Debemos ajustar rápidamente pero con cautela. Idealmente, deberíamos usar sistemas de autenticación modulares para facilitar futuras iteraciones más rápidas.

Debemos reconocer que la criptografía es transitoria; nos da tiempo antes de que los datos se vuelvan inutilizables tras ser descifrados. También debemos ser conscientes de cómo instituciones como la NSA podrían intentar introducir puertas traseras en los kits post-cuánticos.