ML-DSA vs SLH-DSA: assinaturas de reticulado ou de hash

ML-DSA vs SLH-DSA é a principal escolha entre as assinaturas pós-quânticas padronizadas pelo NIST, ambas publicadas em 13 de agosto de 2024. O ML-DSA (FIPS 204, derivado do CRYSTALS-Dilithium) se baseia em reticulados estruturados; o SLH-DSA (FIPS 205, derivado do SPHINCS+) depende apenas da segurança da sua função de hash. Os perfis de tamanho e de velocidade dos dois são tão diferentes que a maioria dos sistemas vai usar o ML-DSA, e o SLH-DSA onde as hipóteses conservadoras dele justificarem o custo.

Visão geral

As velocidades foram medidas com openssl speed em um núcleo de um Apple M4 Max; o ML-DSA do OpenSSL é escrito em C portátil, e implementações otimizadas assinam várias vezes mais rápido.

Hipóteses de segurança

O ML-DSA é um esquema de reticulados do tipo Fiat–Shamir com abortos (Fiat–Shamir with aborts). A segurança dele se apoia nos problemas Module Learning With Errors (aprendizado com erros em módulos) e Module Short Integer Solution, estudados há cerca de duas décadas e que resistiram tanto a ataques clássicos quanto a quânticos, mas cujas estimativas concretas de segurança ainda mudam à medida que as técnicas de redução de reticulados melhoram. O NIST escolheu conjuntos de parâmetros com margens em relação a essas estimativas.

O SLH-DSA constrói as assinaturas a partir de assinaturas baseadas em hash de uso único e de poucos usos, organizadas em uma hiperárvore. Enquanto o SHA-256 ou o SHAKE256 mantiverem a resistência a pré-imagens e as propriedades relacionadas, o SLH-DSA continua seguro; não há estrutura algébrica a atacar. Isso faz dele a assinatura mais conservadora que o NIST padronizou e a salvaguarda natural caso um avanço contra os reticulados aconteça algum dia. Ao contrário dos esquemas baseados em hash com estado LMS e XMSS, ele não precisa de estado: cada chave pode assinar até 2⁶⁴ mensagens.

Tamanhos e velocidade na prática

O script abaixo assina a mesma mensagem com cada algoritmo usando o OpenSSL 3.6.5.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'firmware-2026.10.bin digest' > msg
for alg in ML-DSA-44 ML-DSA-65 SLH-DSA-SHA2-128s SLH-DSA-SHA2-128f ED25519; do
  openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
  openssl pkeyutl -sign -rawin -inkey key.pem -in msg -out sig.bin 2>/dev/null
  openssl pkey -in key.pem -pubout -outform DER -out pub.der 2>/dev/null
  openssl pkey -in key.pem -pubout -out pub.pem 2>/dev/null
  if openssl pkeyutl -verify -rawin -pubin -inkey pub.pem -in msg -sigfile sig.bin >/dev/null 2>&1; then ok=yes; else ok=no; fi
  printf '%-18s public key (SPKI DER) %5s bytes, signature %6s bytes, verifies: %s\n' "$alg" \
    "$(wc -c < pub.der | tr -d ' ')" "$(wc -c < sig.bin | tr -d ' ')" "$ok"
done
cd / && rm -rf "$dir"

ML-DSA-44          public key (SPKI DER)  1334 bytes, signature   2420 bytes, verifies: yes
ML-DSA-65          public key (SPKI DER)  1974 bytes, signature   3309 bytes, verifies: yes
SLH-DSA-SHA2-128s  public key (SPKI DER)    50 bytes, signature   7856 bytes, verifies: yes
SLH-DSA-SHA2-128f  public key (SPKI DER)    50 bytes, signature  17088 bytes, verifies: yes
ED25519            public key (SPKI DER)    44 bytes, signature     64 bytes, verifies: yes

Os perfis são o espelho um do outro. O ML-DSA tem chaves públicas e assinaturas da ordem de kilobytes e assina milhares de vezes por segundo. O SLH-DSA tem chaves públicas minúsculas (tão pequenas quanto as do Ed25519), mas assinaturas de 8 a 50 KB, e os conjuntos s, os pequenos, levam cerca de 137 ms por assinatura nesta máquina (os conjuntos f aceitam assinaturas duas vezes maiores em troca de assinar cerca de 20 vezes mais rápido). A verificação é rápida nos dois. Para uma cadeia de certificados ou um handshake TLS, o ML-DSA é viável e o SLH-DSA não; para uma imagem de firmware assinada uma vez por versão e verificada a cada inicialização, o custo do SLH-DSA é irrelevante, e a chave pública minúscula dele cabe na ROM de boot.

Detalhes operacionais

• Assinatura hedged. Por padrão, as duas normas misturam aleatoriedade nova com valores derivados da chave e permitem uma variante determinística para plataformas sem gerador de números aleatórios; os verificadores não conseguem perceber a diferença.
• Contextos. As duas vinculam a cada assinatura uma string de contexto de até 255 bytes; é recomendável que os protocolos a usem para separar finalidades.
• Variantes pura e com pré-hash. O HashML-DSA e o HashSLH-DSA assinam um digest com o OID do hash vinculado; são algoritmos separados, com OIDs próprios, e o FIPS 204 recomenda usar cada chave em apenas uma das duas variantes.
• Formatos de chave privada. As chaves ML-DSA podem ser armazenadas como a semente de 32 bytes, o que a RFC 9881 permite nas codificações seed ou both; surgem problemas de interoperabilidade quando um dos lados espera a chave expandida.
• Hardware e validação FIPS. Módulos validados com ML-DSA e SLH-DSA passaram a surgir a partir de 2024; confira no certificado do módulo os conjuntos de parâmetros exatos.

Quando escolher cada um

• PKI privada, mTLS interno, assinatura de documentos e de código: ML-DSA-65 (ou 44).
• Firmware, inicialização segura (secure boot), raízes de confiança em hardware: SLH-DSA-128s ou 192s, ou os esquemas com estado LMS e XMSS, que a CNSA 2.0 exige para esse caso, se você conseguir gerenciar o estado do signatário.
• Arquivos de longo prazo e certificados raiz feitos para durar décadas: SLH-DSA, possivelmente ao lado do ML-DSA em uma assinatura dupla.
• Assinatura em grande volume (tokens, transações, logs): ML-DSA; o SLH-DSA não acompanha o ritmo.
• Protocolos com banda limitada: nenhum dos dois é pequeno; o ML-DSA-44 é a menor opção padronizada hoje, e o FN-DSA (rascunho do FIPS 206) busca tamanhos menores.
• TLS público da Web PKI: os navegadores não aceitam nenhum dos dois hoje; veja ML-DSA vs ECDSA para o panorama da transição.

Notas de migração

1. Faça o inventário dos usos de assinatura por tempo de vida e volume: artefatos de longa duração e assinados raramente são candidatos ao SLH-DSA; todo o resto, ao ML-DSA.
2. Escolha versões de bibliotecas que implementem os padrões finais: OpenSSL 3.5 ou posterior (abril de 2025), Bouncy Castle para Java 1.79 ou posterior (1.81 para a codificação padronizada da chave privada), o crypto/mldsa do Go 1.27 para o ML-DSA. As saídas do Dilithium e do SPHINCS+ anteriores aos padrões não são compatíveis.
3. Prepare-se para tamanhos maiores: aumente os limites dos campos de certificado, token e assinatura; certificados ML-DSA-65 têm cerca de 5,5 KB (veja a comparação complementar), e assinaturas SLH-DSA podem exceder os limites comuns de cabeçalhos ou de registros.
4. Considere híbridos durante a transição: certificados compostos de ML-DSA com ECDSA ou EdDSA (um rascunho da IETF) ou assinaturas duplas permitem que os verificadores clássicos continuem funcionando.
5. Fixe a string de contexto e a variante (pura ou com pré-hash) na especificação do seu protocolo, para que todas as implementações concordem.

Referências

• FIPS 204, padrão de assinatura digital baseado em reticulados de módulo
• FIPS 205, padrão de assinatura digital baseado em hash sem estado
• RFC 9881, ML-DSA em X.509
• RFC 9909, SLH-DSA em X.509
• NIST SP 800-208, assinaturas baseadas em hash com estado
• Rascunho público inicial do NIST IR 8547