AES-GCM puede proteger la confidencialidad de un mensaje y detectar cambios no autorizados. Por sí solo no indica al destinatario si un mensaje válido en los demás aspectos ya ha sido procesado.
Es fácil confundir tres requisitos: pares de clave y nonce únicos para el cifrado, autenticación del mensaje y su contexto, y gestión de repeticiones en el protocolo. HKDF puede ayudar a derivar claves, pero no satisface automáticamente los tres.
Reutilizar un nonce y repetir un mensaje son sucesos distintos
| Suceso | Qué ocurre | Protección necesaria |
|---|---|---|
| Reutilización de nonce durante el cifrado | Se cifran textos en claro diferentes con la misma clave GCM y el mismo nonce | Una estrategia fiable de asignación de claves y nonces |
| Manipulación | Se modifica el texto cifrado o el contexto autenticado | Descifrado autenticado y rechazo si falla |
| Repetición | Se entrega de nuevo un mensaje cifrado que antes era válido | Estado y reglas de aplicación que reconocen duplicados o mensajes obsoletos |
| Reordenación | Los mensajes válidos llegan en otro orden | Orden definido por el protocolo y gestión acotada de mensajes fuera de orden |
Un texto cifrado repetido puede seguir teniendo una etiqueta de autenticación válida. No se ha cambiado nada. Por tanto, es incorrecto afirmar que todo duplicado falla automáticamente la autenticación de AES-GCM. RFC 5116 separa explícitamente la interfaz AEAD de los servicios antirrepetición.
Por qué no debe repetirse el par de clave y nonce
El nonce de GCM no necesita ser secreto, pero debe cumplir los requisitos de unicidad del esquema para una clave determinada. Es habitual un nonce de 96 bits, o 12 bytes; elegir esa longitud no garantiza una generación correcta.
Reutilizar la misma clave y el mismo nonce para textos en claro distintos reutiliza el flujo de claves de cifrado y revela relaciones entre esos textos. También puede debilitar la autenticidad y permitir falsificaciones. El impacto es grave, pero no debe describirse como una revelación automática de todas las claves antiguas o de todos los mensajes de una cuenta. El alcance afectado depende de la clave reutilizada y del protocolo.
NIST SP 800-38D define GCM y sus requisitos. Las implementaciones deben seguir los límites de invocación y las reglas de generación de nonces aplicables, no una regla simplista como «seguro hasta esta cantidad de mensajes».
Qué aporta HKDF
HKDF, especificado en RFC 5869, deriva material de claves a partir de material secreto de entrada mediante etapas de extracción y expansión. Los protocolos pueden usar etiquetas de contexto y entradas distintas para separar las claves destinadas a diferentes fines.
HKDF es determinista. Si un cliente que ha fallado o ha vuelto a un estado anterior repite el mismo estado y las mismas entradas, puede derivar otra vez la misma salida. Por tanto, añadir HKDF a un diseño no hace imposible la reutilización de nonces.
Las claves por mensaje pueden reducir la cantidad de contenido protegido por cada clave, pero siguen importando el avance seguro del estado, la separación de claves y su eliminación. El mismo valor de nonce con claves realmente diferentes no constituye el mismo fallo que repetir un par clave/nonce; el protocolo debe establecer que las claves son verdaderamente diferentes.
La protección contra repeticiones pertenece al protocolo
Un destinatario puede registrar identificadores de mensajes, posiciones de secuencia, épocas de sesión o claves de ratchet consumidas. Los campos pertinentes deben estar autenticados para que un atacante no pueda volver a etiquetar un mensaje antiguo como nuevo.
Después, la aplicación debe decidir qué significa un duplicado. Mostrar dos veces una burbuja de chat resulta molesto; ejecutar la misma acción dos veces puede ser más grave. Los reintentos de red son normales, por lo que a menudo se necesita procesamiento idempotente además de comprobaciones criptográficas.
No exija que todos los mensajes válidos lleguen estrictamente en orden salvo que el protocolo especifique ese comportamiento. Los clientes móviles se reconectan, reintentan y reciben mensajes retrasados habitualmente. Una gestión segura distingue un mensaje legítimo que llega tarde de otro ya consumido o con un contexto incorrecto.
Qué probar antes de afirmar que existe protección
- Reiniciar después de asignar un nonce, pero antes de registrar el envío: ¿puede repetirse la asignación?
- Restaurar una instantánea de estado anterior: ¿pueden retroceder las claves, los contadores o los registros de repetición?
- Enviar simultáneamente desde dos procesos de trabajo o dispositivos: ¿están separados sus dominios de clave/nonce?
- Entregar dos veces el mismo mensaje válido: ¿se ejecuta la acción de la aplicación una sola vez?
- Modificar un identificador de sesión o una cabecera: ¿está vinculado criptográficamente el contexto?
- Entregar mensajes válidos fuera de orden: ¿se gestionan los retrasos admitidos sin aceptar un estado obsoleto?
Las API de descifrado autenticado deben devolver texto en claro a la aplicación solo cuando la verificación sea correcta. Es un requisito de la interfaz, no una afirmación de que ninguna implementación calcule jamás internamente un búfer temporal de texto en claro.
Interpretar con precisión las afirmaciones de Livara
La documentación de seguridad de Livara menciona AES-256-GCM, cadenas por mensaje y contexto LVR1/LGS1. Estas primitivas no demuestran por sí solas una recuperación correcta tras fallos, una asignación correcta de nonces ni el rechazo de repeticiones. Tales afirmaciones requieren detalles del protocolo con versiones identificadas y pruebas documentadas.
Un diseño sólido asigna explícitamente cada tarea: la derivación de claves crea las claves previstas, AEAD autentica contenido y contexto, y la lógica del protocolo con estado decide si un mensaje válido es aceptable ahora.
