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

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

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

4/ Ingrese el nonce: un "número usado una vez" que evita los ataques de repetición. Cuando un consumidor recibe un mensaje con un nonce, comprueba si ese nonce se usó antes. En caso afirmativo, → rechazar. Las transacciones de Ethereum utilizan este patrón.

5/ Pero la implementación del nonce es engañosamente compleja. Requisitos clave: - Los nonces NUNCA deben ser reutilizables (en esta cadena u otras) - Debe evitar ataques de repetición de forma permanente - Necesita mecanismos para manejar el crecimiento del almacenamiento - Debe ser resistente a los ataques frontales

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

7/ ¡Los nonces basados en marcas de tiempo resuelven el crecimiento del almacenamiento! Utilice la marca de tiempo + el período de caducidad. Los nonces de más 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/ Correr al frente es la parte difícil. Los actores maliciosos pueden interceptar firmas válidas, adelantarlas para marcar nonces como usados y luego se rechaza la llamada del usuario legítimo. Esto es problemático en cadena con operaciones por lotes si una firma incorrecta rechaza un lote completo. Para fuera de la cadena: ¡use el cifrado TLS! No permita que ningún actor malicioso vea el nonce o la firma.

9/ ¡No olvides la persistencia! Si su caché de nonce solo está en la memoria, los atacantes pueden reproducir nonces antiguos después de reiniciar el sistema. Conserve siempre el estado nonce en el almacenamiento duradero y vuelva a cargar al inicio. Caché de solo memoria = ventana de vulnerabilidad de reproducción.

10/ ¡Nonces únicos por consumidor! Al transmitir a varios usuarios, cada uno debe recibir un mensaje / firma diferente. De lo contrario, eres vulnerable a los ataques Man-in-the-Middle en los que un receptor reenvía el mensaje, haciéndose pasar por el remitente original.

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

Resumen - Lista de verificación de implementación de nonce: ✅ Use nonces para evitar ataques de repetición ✅ Conservar el estado de nonce en los reinicios ✅ Implementar mecanismos de caducidad (marca de tiempo + limpieza) ✅ Haga que los nonces sean únicos por receptor ✅ Protéjase contra el front-running con canales cifrados ✅ Evite los nonces incrementales a menos que se garantice el orden ¡La seguridad está en los detalles! 🛡️