¿Crees que implementar nonces es simple? Piénsalo de nuevo. Ya sea que estés construyendo protocolos en cadena o infraestructura fuera de la cadena, la implementación adecuada de nonces es una de las partes más complicadas de la seguridad criptográfica. Vamos a profundizar en por qué la protección contra la repetición es más difícil de lo que parece 👇

2/ Primero, entendamos las firmas digitales. En la criptografía de clave pública (como BLS), tienes una clave privada que firma mensajes y una clave pública que los verifica. En Ethereum: dirección = hash de la clave pública mensaje = hash de la transacción firma = 64 bytes de prueba criptográfica

3/ Aquí está el problema: las matemáticas en la mayoría de los protocolos de criptografía de clave pública no limitan cuántas veces se puede verificar una firma contra el mismo mensaje. Una vez que tienes una firma válida, puedes reproducirla infinitamente. Esto abre la puerta a ataques de reproducción.

4/ Introduce el nonce: un "número que se usa una vez" que previene ataques de repetición. Cuando un consumidor recibe un mensaje con un nonce, verifica si ese nonce se ha utilizado antes. Si es así → rechazar. Las transacciones de Ethereum utilizan este patrón.

5/ Pero la implementación de nonces es engañosamente compleja. Requisitos clave: - Los nonces NUNCA deben ser reutilizables (en esta cadena o en otras) - Deben prevenir ataques de repetición de forma permanente - Necesitan mecanismos para manejar el crecimiento del almacenamiento - Deben ser resistentes a ataques de front-running

6/ La solución ingenua: almacenar todos los nonces en una base de datos para siempre. Esto tiene dos problemas principales: a) Crecimiento de almacenamiento sin límites (especialmente con ataques de spam) b) Vulnerabilidad a ataques de front-running El problema (a) es más fácil de resolver que el (b). Primero abordemos el almacenamiento...

7/ ¡Los nonces basados en marcas de tiempo resuelven el crecimiento del almacenamiento! Usa marca de tiempo + período de caducidad. Los nonces más antiguos de 5 minutos se eliminan de la base de datos. Pero, ¿qué pasa con los mensajes simultáneos de la misma cuenta? Comparten una marca de tiempo. Solución: marca de tiempo + random_bytes para una unicidad granular.

8/ El front-running es la parte complicada. Los actores maliciosos pueden interceptar firmas válidas, hacer front-running para marcar nonces como utilizados, y luego la llamada del usuario legítimo es rechazada. Esto es problemático en la cadena con operaciones agrupadas si una mala firma rechaza todo un lote. Para fuera de la cadena: ¡usa cifrado TLS! No dejes que ningún actor malicioso vea nunca el nonce o la firma.

9/ ¡No olvides la persistencia! Si tu caché de nonces está solo en memoria, los atacantes pueden reproducir nonces antiguos después de reinicios del sistema. Siempre persiste el estado de los nonces en un almacenamiento duradero y recárgalo al iniciar. Las cachés solo en memoria = ventana de vulnerabilidad de reproducción.

10/ ¡Nonces únicos por consumidor! Al transmitir a múltiples usuarios, cada uno debe recibir un mensaje/firma diferente. De lo contrario, eres vulnerable a ataques de Man-in-the-Middle donde un receptor reenvía el mensaje, suplantando al remitente original.

11/ Los nonces incrementales (como en Ethereum, nonce = nonce anterior + 1) tienen su lugar, ¡pero cuidado! Crean enormes desafíos para la infraestructura fuera de la cadena: mensajes fuera de orden, problemas de sincronización y escenarios de recuperación complejos. Úsalos solo si estás seguro de que los mensajes llegarán (o deben llegar) en secuencia.

Resumen - Lista de verificación de implementación de nonces: ✅ Utilizar nonces para prevenir ataques de repetición ✅ Persistir el estado de los nonces a través de reinicios ✅ Implementar mecanismos de expiración (marca de tiempo + limpieza) ✅ Hacer que los nonces sean únicos por receptor ✅ Proteger contra el front-running con canales encriptados ✅ Evitar nonces incrementales a menos que el orden esté garantizado ¡La seguridad está en los detalles! 🛡️