Resumo

  • Sem atributos assinados, o ML-DSA puro assina diretamente os octetos do conteúdo; digestAlgorithm deve indicar SHA-512 por compatibilidade, mas seu valor deve ser ignorado pelo verificador.
  • Com atributos assinados, o digest do conteúdo integra a matéria protegida, precisa ser recalculado e comparado e pode limitar a resistência da composição.
  • Uma trilha defensável separa a ramificação CMS, os bytes exatos, o OID do conjunto de parâmetros, a comparação do digest, a proteção de algoritmos, as fronteiras da chave e de μ, a autorização e o efeito posterior.

Três linhas verdes em um painel—SHA-512, ML-DSA-65 e assinatura válida—podem estar factualmente corretas. Ainda assim, não demonstram que SHA-512 resumiu o conteúdo entregue ao ML-DSA, que a chave privada permaneceu em um HSM ou que o titular identificado tinha poder para autorizar a operação.

Publicado em outubro de 2025 como Proposed Standard do IETF, o RFC 9882 define o uso dos conjuntos ML-DSA-44, ML-DSA-65 e ML-DSA-87 do FIPS 204 na Cryptographic Message Syntax. Cada conjunto possui seu próprio OID de assinatura, e os parâmetros do respectivo AlgorithmIdentifier devem estar ausentes. O documento trata do ML-DSA puro, não especifica HashML-DSA em CMS e alerta que ML-DSA, antes chamado Dilithium, não é compatível com ele.

O significado da verificação começa na presença ou ausência de signedAttrs.

Sem atributos assinados, a entrada do ML-DSA são os octetos que compõem o valor do OCTET STRING em encapContentInfo eContent. Os octetos de tag e comprimento ficam de fora. Como o ML-DSA puro processa a mensagem inteira, SignerInfo.digestAlgorithm não exerce função no cálculo da assinatura nessa ramificação.

Mesmo assim, o emissor deve informar SHA-512 para reduzir falhas de interoperabilidade. O receptor, por sua vez, deve ignorar o conteúdo do campo. A indicação é evidência de uma convenção de compatibilidade, não de um digest externo consumido pelo algoritmo. Um coletor pode registrar o valor sem erro e, ainda assim, um relatório pode lhe atribuir uma função inexistente.

Quando signedAttrs está presente, muda o objeto assinado. A entrada passa a ser a codificação DER completa do valor SignedAttrs, inclusive tag e comprimento, usando a tag EXPLICIT SET OF em vez da IMPLICIT [0] do objeto final. Os atributos precisam conter ao menos content-type e message-digest. Este último guarda o hash do conteúdo, que o destinatário deve recalcular e comparar. Aqui o digest influencia de fato a construção, e uma escolha fraca pode fixar seu teto de segurança. Suporte a SHA-512 é obrigatório; SHAKE256 é recomendado e seus parâmetros também devem estar ausentes.

Uma diferença sintática pequena produz duas leituras opostas do mesmo campo. Um resultado que não registre primeiro a ramificação não explica o que foi assinado, se houve comparação do conteúdo ou qual papel o digest teve. “Válida” descreve o resultado matemático, não toda a cadeia probatória.

A identidade do algoritmo é outro controle. O verificador deve conferir o OID do conjunto ML-DSA e rejeitar parâmetros proibidos. O CMSAlgorithmProtection, do RFC 6211, leva os identificadores relevantes para dentro de um atributo assinado. O RFC 9882 recomenda sua inclusão para evitar substituição de algoritmo. Presença e coerência precisam de constatação própria; não nascem automaticamente da validade da assinatura.

A custódia da chave fica fora desse veredicto. O comprometimento da chave privada ML-DSA permite falsificação. O FIPS 204 adota por padrão uma geração hedged, combinando aleatoriedade nova com dados aleatórios pré-calculados na chave, e permite geração determinística. O RFC 9882 desaconselha o modo determinístico onde ataques de canal lateral ou de falha sejam uma preocupação. O objeto CMS não revela sozinho qual política foi aplicada.

Um módulo de hardware acrescenta uma fronteira, não a elimina. Com atributos assinados, o sistema pode enviar ao HSM apenas a estrutura DER menor. O representante de mensagem μ também pode ser calculado em outro módulo criptográfico e fornecido ao assinador. Portanto, “gerado no HSM” não prova que o equipamento recebeu o conteúdo original nem que calculou μ. A interface e o vínculo com os bytes preservados precisam ser auditados.

O registro completo preserva o CMS original, anota a presença dos atributos, reconstrói a entrada exata, identifica o OID e recusa parâmetros indevidos. Quando cabível, recalcula e compara o digest; depois verifica a proteção dos algoritmos e a assinatura. A política de aleatoriedade, a origem de μ, a cadeia de certificados, a identidade, a autorização da aplicação e o efeito final entram como fatos separados.

Fontes