XAES-256-GCM AEAD de nonce extendido

Introducción a XAES-256-GCM

• XAES-256-GCM es un algoritmo de cifrado autenticado (AEAD) que usa una clave de 256 bits y un nonce de 192 bits
• Objetivos principales:
  • admitir de forma segura nonces generados aleatoriamente
  • cumplimiento de FIPS 140
  • implementación sencilla en bibliotecas de cifrado comunes

Objetivos de diseño de XAES-256-GCM

• Uso de un nonce grande para poder generarlo aleatoriamente de forma segura para una cantidad ilimitada de mensajes
• Posibilidad de uso en diversos entornos gracias al cumplimiento de FIPS 140
• Reducción de la carga para el usuario mediante una implementación simple

Principio de funcionamiento de XAES-256-GCM

• Usa una estructura de nonce extendido basada en AES-256-GCM
• Calcula una clave derivada usando la clave de entrada y el nonce
• Procesa el mensaje con tres llamadas a AES-256

Implementación y optimización

• La implementación de referencia en Go consta de menos de 100 líneas de código
• Usa únicamente crypto/cipher y crypto/aes de la biblioteca estándar
• Puede describirse usando NIST SP 800-108r1 KDF y NIST AES-256-GCM AEAD

Implementaciones de terceros y compatibilidad

• Existen implementaciones de terceros en .NET 8+, pyca/cryptography y Web Cryptography API
• No es posible cambiar el número de rondas para mantener el cumplimiento de FIPS 140

Alternativas y vectores de prueba

• Existen varias alternativas, como AES-GCM-SIV
• Incluye vectores de prueba para las rutas de código principales

Resumen

• XAES-256-GCM está diseñado como un AEAD seguro, conforme e interoperable
• Cumple un papel complementario a XChaCha20Poly1305 y AES-GCM-SIV
• Se espera que pueda añadirse a la biblioteca estándar de Go

Opinión de GN⁺

• Destaca el uso de un nonce grande para mejorar la seguridad
• Puede utilizarse en diversos entornos gracias al cumplimiento de FIPS 140
• Su implementación sencilla en lenguajes como Go lo hace útil para desarrolladores
• También vale la pena considerar alternativas como AES-GCM-SIV
• Al adoptar una nueva tecnología, conviene evaluar cuidadosamente el rendimiento y la compatibilidad

[GN⁺]

Comentarios de Hacker News

• El diseño es muy ingenioso: basado en CMAC, puede derivar la clave usando AES-CBC cuando no hay primitivas de bajo nivel disponibles

  • Explicado en términos de AES-CBC:

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. si MSB₁(L) = 0, entonces K1 = L << 1;
       de lo contrario K1 = (L << 1) ⊕ 0¹²⁰10000111
    3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
    4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
    5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
    6. Nₓ = N[12:]
    

  • AES-CBC-256 devuelve el primer bloque de 128 bits y descarta el bloque con padding
  • Después de derivar la clave, se usa con AES-GCM estándar
  • Ejemplo de implementación en JS basada en la WebCrypto API: enlace de GitHub
  • Acepta una CryptoKey adecuada pensada para AES-CBC, y puede guardarse en IndexedDB

• El trabajo de Filippo es excelente: resuelve el problema de tener que rotar la clave cada ~2^32 mensajes cuando se usan nonces aleatorios

  • En AES-GCM, una colisión de nonce es catastrófica (permite que un atacante firme mensajes arbitrarios)
  • No es obligatorio usar nonces aleatorios, pero por lo general se recomiendan
  • Es muy ingenioso que lo haya hecho compatible con FIPS usando dos primitivas (un KDF basado en contador y GCM común)

• Ojalá esto hubiera existido hace unos años cuando escribí un sistema de archivos cifrado

  • Las colisiones de nonce son un gran problema en despliegues de sistemas de archivos a gran escala
  • 2^32 parece grande, pero en arreglos de PB que escriben 100k IOPS, si dependes de la aleatoriedad del PRNG, una colisión está prácticamente garantizada

• Espero que esto se use en una variante compatible con FIPS de age[1] para cifrado de archivos de archivo

  • Los auditores de la industria bancaria se oponían a age por no usar AES en vez de ChaCha (la parte de clave pública X25519 fue aprobada recientemente por NIST)
  • No tengo experiencia con golang, pero parece que podría aplicarse fácilmente siguiendo la especificación de age
  • Lo intentaré si el tiempo me lo permite
  • Lo llamaría "cage" (siglas de "compliant actually good encryption")

• Pregunta de un no criptógrafo: me intriga por qué usar un nonce de 192 bits y no de 256 bits

  • En aplicaciones prácticas no parece que los bits extra vayan a costar mucho

• (riesgo de colisión de 2⁻³² con 2⁸⁰ mensajes)

  • Como el tamaño de bloque de AES es de 128 bits, me pregunto si no podría haber problemas antes de eso