Cripto post-cuántica en ESP32: seguridad IoT 2026

Los microcontroladores de bajo costo como el ESP32-S3 ahora pueden ejecutar criptografía post-cuántica ML-KEM-768 en apenas 9.6 milisegundos, ofreciendo protección contra ataques cuánticos futuros sin sacrificar el rendimiento. El proyecto esp32-awp-edge demostró que es posible implementar intercambio de claves resistente a computadoras cuánticas en hardware de $5 con código abierto y sin compromisos de seguridad.

¿Qué es la criptografía post-cuántica?

Ponele que hoy cifras datos ultra-sensibles con RSA 2048 bits. Cifrás, guardás, y te vas tranquilo pensando que en 20 años seguirá siendo seguro. Ojo: si alguien graba ese tráfico cifrado ahora, puede guardarla congelada en un repositorio cuántico y descifrarlo en 2045 cuando la tecnología cuántica sea viable. Eso se llama “harvest now, decrypt later” (cosechat hoy, descifrá después).

La criptografía post-cuántica (PQC) es el conjunto de algoritmos matemáticos diseñados para resistir ataques tanto de computadoras clásicas como cuánticas, basados en problemas matemáticos complejos como retículas (lattices) que requieren exponencialmente más operaciones para romper, incluso con computadoras cuánticas.

No usa fenómenos cuánticos. No necesita hardware especial. Es matemática pura. ML-KEM, el estándar que vamos a ver, se basa en el Kyber original pero con auditoría formal de NIST. La idea es migrar hoy a algoritmos que serán seguros dentro de 15, 20, 30 años.

Por qué IoT necesita post-quantum crypto ahora

IoT tiene un problema temporal distinto al de las laptops o servidores. Un sensor que mandás a un campo en 2026 puede estar transmitiendo datos sensibles durante 10, 15, 20 años. Cifrado RSA hoy podría ser transparente en 2046. Eso no es paranoia. Es sentido común si las claves que guardás hoy serán presa de máquinas cuánticas comerciales en una década.

Además: hay requisitos regulatorios crecientes. En sectores como healthcare, finanzas y defensa, los datos de largo plazo (certificados digitales, credentials, audit logs) ya necesitan protección cuántica preventiva. No esperas a que la amenaza sea real. La migras antes.

El overhead computacional en IoT es material: más CPU, más energía, más ancho de banda. Pero si podés correr la operación en 10 milisegundos en un chip de $5, el juego cambió. Ya no es “es imposible en IoT”, es “hay que hacerlo diferente, pero se puede”.

ML-KEM-768: el estándar NIST para intercambio de claves

Hace poco NIST publicó FIPS 203 con los algoritmos post-cuánticos oficiales. ML-KEM (machine learning key encapsulation mechanism, nombre eufemístico para “Kyber revisado”) fue seleccionado para intercambio de claves. Te puede servir nuestra cobertura de en nuestro análisis de seguridad.

Viene en tres tamaños: 512 (menor seguridad, más velocidad), 768 (balance), 1024 (máxima seguridad). Para IoT, 768 es el sweet spot. Usás 768 porque:

• Resiste contra ataques clásicos y cuánticos a nivel NIST Level 3 (equivalente a AES-192)
• Es lo suficientemente rápido: 10ms de encapsulación en hardware modesto
• No es overkill como 1024 (que sería Level 5, más lento innecesariamente)

Lo interesante es que ML-KEM se basa en problemas de retículas, no en factorización como RSA. Las retículas son algebraicamente distintas. Los algoritmos cuánticos conocidos (Shor, Grover) no aplican. Alguien podría descubrir un ataque cuántico a retículas, claro, pero la comunidad criptográfica lleva años buscándolo. No existe, y NIST apostó por eso.

Implementación de ML-KEM-768 en ESP32-S3

El proyecto esp32-awp-edge hizo lo difícil: tomó el estándar NIST y lo ejecutó en un microcontrolador de $5. No es un PoC frágil. Es una implementación de producción con arquitectura clara.

El stack es:

• ML-KEM-768: intercambio de claves (nueva sesión cada vez)
• BLAKE3-256: derivación de claves y integridad de frames
• XChaCha20-Poly1305: cifrado simétrico de payload (nonces de 192 bits, no reutilizables)

El firmware ocupa 833 KB. Quedan 157 KB de heap disponible. Zero fallback a texto plano. Si el encapsulador falla, la conexión se rechaza. Nada de “bueno, al menos podemos comunicar sin seguridad”.

Usaron mlkem-native v1.0.0 para ML-KEM, que pasó auditoría formal independiente. La validación ocurre en 13 pruebas criptográficas en arranque: checksum de código, test de generador de nonces, test de integridad de BLAKE3, etc. (sí, en serio hacen eso en cada boot).

Benchmarks reales: rendimiento en hardware

Los números no mienten. Acá están los tiempos en ESP32-S3 (spoiler: son mejores de lo que esperabas):

¿Cuánto más lento que criptografía tradicional? Curve25519 toma alrededor de 4-5 ms en ESP32. ML-KEM-768 toma 10 ms. Relación: 2.3x más lento.

Eso no es poco. Pero tampoco es “hace que el dispositivo sea inutilizable”. En una sesión que dura horas (o días), 20 milisegundos de overhead inicial para clave segura cuánticamente es una ganga. Relacionado: entre las herramientas esenciales.

Arquitectura de seguridad: capas de defensa

El proyecto no solo metió ML-KEM y listo. Construyó capas de defensa, tipo cebolla.

Capa 1: Intercambio de claves (ML-KEM-768). Client y server acuerdan un shared secret de 32 bytes. Las claves públicas son enormes (1184 bytes), pero el secret compartido es compacto. Ese secret nunca se transmite por la red, solo se encapsula criptográficamente.

Capa 2: Integridad de frames (BLAKE3). Cada frame (mensaje) lleva un MAC (message authentication code) generado con BLAKE3. Si alguien modifica un byte del payload, el MAC no valida. Detectás tampering instantly.

Capa 3: Cifrado simétrico (XChaCha20-Poly1305). El payload se cifra con la clave derivada. XChaCha usa nonces de 192 bits, así que los riesgos de colisión de nonce son negligibles incluso en 2^64 mensajes.

La desencapsulación de ML-KEM corre en tiempo constante. Eso significa: sin importar la entrada, tarda lo mismo. Evitás timing attacks (donde alguien mide cuánto tarda la operación para deducir información de la clave). Es un detalle que muchos ignoran, pero que marca la diferencia entre código criptográfico de juguete y producción.

Overhead: claves grandes vs seguridad cuántica

ML-KEM-768 no viene gratis. Trade-offs reales:

• Tamaño de claves: pública = 1184 bytes, privada = 2400 bytes. Comparate con ECDH: public key 32 bytes (256 bits), privada 32 bytes. ML-KEM es ~37x más grande en público, ~75x en privado. Para un sensor IoT con almacenamiento limitado, eso importa.
• Overhead de red: cada handshake envía ~1200 bytes de clave pública vs ~100 bytes con ECDH. En dispositivos con datos móviles limitados o bandwidth constreñido (LoRaWAN, NB-IoT), esto es un hit.
• Energía: 10ms de CPU en un microcontrolador = batería que drena más rápido. 20mJ por sesión (estimado). Si estás renovando claves cada hora, suma.

El panorama: ninguno de esos problemas es imposible de resolver. Es cuestión de diseño. Acordate que generás la clave una vez por sesión (que puede durar horas o días). El overhead se amortiza rápido.

Casos de uso: dónde ya se implementa

¿Quién necesita esto hoy? No es teórico.

Dispositivos IoT críticos en healthcare. Un monitor cardíaco conectado que transmite datos en vivo durante años. Si esos datos se cifran hoy con RSA y alguien los guarda, en 2050 los descifra. Con ML-KEM-768, ese riesgo desaparece. La empresa que fabrica esos monitores ya lo está implementando. En en repositorios de proyectos abiertos profundizamos sobre esto.

Firmware updates firmados. Un sensor industrial que vive 15 años en el campo. Recibe actualizaciones de firmware firmadas. La firma se verifica con una clave pública guardada en ROM. Si esa firma estuviera con RSA y alguien falsificara una actualización (cifrada), en 2045 podría crackearla retroactivamente y comprometer miles de dispositivos. Con PQC, eso no pasa.

Credenciales de largo plazo. Certificados, API keys, tokens. Datos que se emiten hoy pero se usan durante años. Si se guardan encrypted, hoy con algo cuántico-seguro mañana no hay problema. Fintech y banca ya migran.

El patrón: cualquier dato que tenga valor información a 10+ años vista debería considerarse PQC hoy. Es como cambiar a HTTPS. Al principio “¿para qué?”, después “¿cómo vivíamos sin esto?”.

Tabla comparativa: ML-KEM-768 vs alternativas

El resumen: si te importa la velocidad pura y la resistencia cuántica no es crítica, seguís con Curve25519. Si necesitás cuántico-safe hoy y podés tolerar 2.3x overhead, ML-KEM-768 es tu elección. RSA es lento y cuántico-vulnerable, no tiene sentido hoy.

Errores comunes

Creer que PQC es “para el futuro”

“Los atacantes cuánticos no existen todavía, ¿para qué migrar ahora?” Esto es backwards. Los datos sensibles cifrados hoy son el activo que atacantes cuánticos van a perseguir en 2045. Si guardás secretos de 20 años, encriptá con criptografía de 20 años. La migración es lenta, toma años, mejor empezás ya.

Mezclar ML-KEM con RSA como “backup”

Un error común: “usemos ML-KEM Y RSA, así cubrimos ambos casos”. Suena lógico, pero en realidad duplicás el overhead, complicás el código, y si RSA falla, el adversario puede forzarte a usar la rama RSA insegura. El esp32-awp-edge hace lo correcto: ML-KEM únicamente, o rechazá la conexión. Punto. Lo explicamos a fondo en con pipelines de automatización moderna.

No revisar el tamaño de claves en almacenamiento

1184 bytes de clave pública por dispositivo. Si manejás 10 mil dispositivos y guardás todas las keys, son ~12 MB. Manejable. Pero si tenés 1 millón, son 1.2 GB de solo keys. Necesitás una estrategia de almacenamiento (DB indexada, rotación de keys, etc.). No es “meto la key en EEPROM y listo”.

Preguntas Frecuentes

¿Cuál es la diferencia entre criptografía cuántica y post-cuántica?

Criptografía cuántica (quantum key distribution, QKD) usa fenómenos cuánticos reales (polarización de fotones, etc.) para detectar escuchas. Es física. Post-cuántica es matemática clásica que resiste ataques cuánticos. QKD es hardware costoso, punto-a-punto. PQC es software, para Internet. Para IoT, PQC es el camino.

¿Necesito cambiar mi hardware si migro a ML-KEM-768?

No. ESP32-S3, STM32, nRF52, y otros micros estándar corren ML-KEM sin problemas. Tarda 10ms, consume ~20mJ. Si tu hardware hace anything más complejo (WiFi, BLE), ese overhead es ruido. Solo monitoreá RAM (necesitás ~10KB de stack).

¿Qué pasa si un atacante graba mi tráfico hoy, cifrado con PQC?

Nada. En 2050 cuando tenga computadoras cuánticas, los datos siguen cifrados. El shared secret de 32 bytes que derivaste con ML-KEM-768 requeriría computación cuántica para invertir. Así que tu secreto de 2026 sigue siendo secreto en 2050. Eso es el objetivo.

¿ML-KEM-768 es más seguro que RSA-4096?

Para ataques clásicos, depende del parámetro. NIST Level 3 (768) equivale a AES-192 en dificultad clásica, y RSA-3072 (no 4096). Pero RSA es vulnerable a ataques cuánticos futuros. 768 no. No es “más seguro vs menos seguro”, es “seguro contra dos amenazas vs una”.

¿Puedo implementar esto en Arduino o PIC micro?

Arduino clásico (ATmega) tiene 2KB RAM. ML-KEM-768 necesita ~10KB. No cabe. Arduino Due o Teensy sí. Los PIC modernos (PIC24, dsPIC33) tienen RAM suficiente pero menos biblioteca de soporte. ESP32-S3 hoy es la opción más accesible. STM32H7 también funciona bien.

Conclusión

La criptografía post-cuántica dejó de ser un “algún día” para IoT. El esp32-awp-edge demostró que ML-KEM-768 corre en microcontroladores estándar con rendimiento aceptable: 10 milisegundos de encapsulación, sesiones seguras en 226ms, y protección contra amenazas cuánticas futuras. El overhead existe (2.3x más lento que ECDH, claves 70x más grandes), pero es un precio que vale si los datos que estás protegiendo importan a largo plazo.

Para cualquiera que fabrique dispositivos con datos de largo plazo (healthcare, finanzas, infraestructura), debería evaluar PQC en 2026. No en 2030 cuando las computadoras cuánticas sean noticia de portada. Ahora. El estándar existe, hay código open source, y el hardware es económico. Solo falta la migración.

Fuentes

• esp32-awp-edge – Implementación open source de ML-KEM-768 en ESP32-S3
• NIST FIPS 203 – ML-KEM estándar oficial post-cuántico
• ArXiv 2503.10207 – Benchmarks y análisis detallado de ML-KEM-768 en ESP32
• WolfSSL – Post-Quantum Key Share en ESP32
• Kivi Core – ML-KEM explicado para hardware embebido