XAES-256-GCM: AEAD com nonce estendido

Introdução ao XAES-256-GCM

• XAES-256-GCM é um algoritmo de criptografia autenticada (AEAD) que usa uma chave de 256 bits e um nonce de 192 bits
• Objetivos principais:
  • oferecer suporte seguro a nonces gerados aleatoriamente
  • conformidade com FIPS 140
  • implementação fácil em bibliotecas de criptografia comuns

Objetivos de design do XAES-256-GCM

• Uso de um nonce grande para permitir geração aleatória segura para uma quantidade ilimitada de mensagens
• Possibilidade de uso em diversos ambientes por meio da conformidade com FIPS 140
• Implementação simples para reduzir a carga sobre o usuário

Como o XAES-256-GCM funciona

• Usa uma estrutura de nonce estendida baseada em AES-256-GCM
• Calcula uma chave derivada usando a chave de entrada e o nonce
• Processa a mensagem com três chamadas de AES-256

Implementação e otimização

• A implementação de referência em Go tem menos de 100 linhas de código
• Usa apenas crypto/cipher e crypto/aes da biblioteca padrão
• Pode ser descrito usando NIST SP 800-108r1 KDF e NIST AES-256-GCM AEAD

Implementações de terceiros e compatibilidade

• Há implementações de terceiros em .NET 8+, pyca/cryptography e Web Cryptography API
• Não é possível alterar o número de rodadas para manter a conformidade com FIPS 140

Alternativas e vetores de teste

• Existem várias alternativas, como AES-GCM-SIV
• Inclui vetores de teste para os principais caminhos de código

Resumo

• XAES-256-GCM foi projetado como um AEAD seguro, compatível e interoperável
• Atua como complemento ao XChaCha20Poly1305 e ao AES-GCM-SIV
• Espera-se que seja adicionado à biblioteca padrão do Go

Opinião do GN⁺

• O uso de um nonce grande no XAES-256-GCM é um ponto notável por aumentar a segurança
• A conformidade com FIPS 140 permite seu uso em diversos ambientes
• Sua implementação fácil em linguagens como Go o torna útil para desenvolvedores
• Também vale a pena considerar alternativas como AES-GCM-SIV
• Ao adotar uma nova tecnologia, é preciso avaliar cuidadosamente desempenho e compatibilidade

[GN⁺]

Comentários do Hacker News

• O design é muito inteligente: baseado em CMAC, permitindo derivar a chave usando AES-CBC quando primitivas de baixo nível não estão disponíveis

  • Explicando em termos de AES-CBC:

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. MSB₁(L) = 0이면, K1 = L << 1;
       그렇지 않으면 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 retorna o primeiro bloco de 128 bits, e o bloco com padding é descartado
  • Usado junto com AES-GCM padrão após derivar a chave
  • Exemplo de implementação em JS baseado na WebCrypto API: link do GitHub
  • Aceita uma CryptoKey apropriada destinada a AES-CBC, podendo ser armazenada no IndexedDB

• O trabalho do Filippo é excelente: resolve o problema de ter que rotacionar a chave a cada cerca de 2^32 mensagens ao usar nonces aleatórios

  • Em AES-GCM, colisões de nonce são catastróficas (permitindo que um atacante assine mensagens arbitrárias)
  • Não é necessário usar nonces aleatórios, mas isso normalmente é recomendado
  • Foi muito inteligente torná-lo compatível com FIPS usando duas primitivas (KDF baseado em contador e GCM comum)

• Eu gostaria que isso existisse alguns anos atrás, quando escrevi um sistema de arquivos criptografado

  • Colisões de nonce são um grande problema em implantações de sistemas de arquivos em larga escala
  • 2^32 parece muito, mas em arrays de PB gravando 100k IOPS, colisões são praticamente garantidas se você depender da aleatoriedade do PRNG

• Espero que isso seja usado em uma variante compatível com FIPS do age[1] para criptografia de arquivos de arquivo

  • Auditores da indústria bancária se opuseram ao age por ele não usar AES em vez de ChaCha (a parte de chave pública X25519 foi aprovada recentemente pelo NIST)
  • Não tenho experiência com golang, mas parece fácil de aplicar de acordo com a especificação do age
  • Vou tentar se tiver tempo
  • Vou chamá-lo de "cage" (sigla para "compliant actually good encryption")

• Pergunta de um não criptógrafo: por que usar um nonce de 192 bits e não de 256 bits?

  • Em aplicações práticas, não parece que os bits extras teriam um custo alto

• (risco de colisão de 2⁻³² em 2⁸⁰ mensagens)

  • Como o tamanho de bloco do AES é 128 bits, fico pensando se algum problema pode surgir antes disso