Assinatura Pós-Quântica Chega Silenciosamente: ML-DSA para Documentos Word no .NET

💡 Exemplo completo em funcionamento disponível no GitHub:
sign-word-with-ml-dsa-certificates-dotnet

O Antigo Caminho Era um Plano de Projeto

Pergunte o que é necessário para tornar a assinatura de documentos pós‑quântica e você receberá um roteiro: avaliar algoritmos, escolher uma biblioteca, escrever uma camada de abstração sobre o código de assinatura, planejar um período de assinatura dupla, orçar um trimestre.

A maior parte disso ainda é válida para a metade organizacional – aquisição de certificados, política, suporte a validadores. A metade de código acabou sendo menor do que o roteiro sugere, e isso vale a pena saber antes que alguém orce um trimestre para isso.

A assinatura ML-DSA é um recurso do GroupDocs.Signature para .NET que assina documentos Word com certificados baseados no FIPS 204, o padrão de assinatura pós‑quântica do NIST. Ela chegou na versão 26.9 e, do ponto de vista do código que a chama, trata‑se de um arquivo PFX diferente.

Existe um Caminho Melhor

Aqui está toda a mudança de código:

using var signature = new Signature(sourcePath);

var options = new DigitalSignOptions(pfxPath)
{
    Password = certificatePassword
};

SignResult result = signature.Sign(outputPath, options);

Essa é a mesma chamada usada para um certificado RSA. O algoritmo é uma propriedade do certificado, portanto nenhuma opção o seleciona, nenhuma camada de abstração é necessária e nenhum caminho de código secundário aparece para o período de transição. Aponte DigitalSignOptions para um PFX ML‑DSA e a saída será uma assinatura ML‑DSA.

Ler o certificado de volta a partir do resultado vale a pena enquanto vários certificados estão em uso:

var created = result.Succeeded.OfType<DigitalSignature>().FirstOrDefault();
return created?.Certificate?.Subject ?? "(no certificate returned)";

Escolhendo um Nível, Com Números Em vez de Opiniões

ML‑DSA vem em três conjuntos de parâmetros, correspondendo às categorias de segurança NIST 2, 3 e 5. Mais forte significa maior – tanto a chave quanto a assinatura – e a forma sensata de decidir é assinar seu próprio documento três vezes e observar:

var levels = new Dictionary<string, string>
{
    ["ML-DSA-44"] = MlDsa44Pfx,
    ["ML-DSA-65"] = MlDsa65Pfx,
    ["ML-DSA-87"] = MlDsa87Pfx
};

O exemplo grava uma cópia assinada por nível e registra cada tamanho, portanto o trade‑off é uma medição e não uma tabela de especificação. Para um único contrato a diferença é insignificante; para um arquivo com vários milhões de documentos assinados, trata‑se de uma questão de capacidade que vale a pena considerar antes de padronizar no nível mais alto.

ML‑DSA‑65 é o padrão razoável quando nenhuma política especifica um. Perfis como CNSA 2.0 nomeiam explicitamente o ML‑DSA‑87, e o ML‑DSA‑44 faz sentido apenas quando o tamanho importa mais que a margem.

A Verificação Precisa Apenas do Certificado Público

A história de distribuição permanece a mesma do RSA, que é a segunda boa notícia:

var options = new DigitalVerifyOptions(certificatePath);
if (password != null)
{
    options.Password = password;
}

VerificationResult result = signature.Verify(options);

Um destinatário precisa apenas do .cer do assinante e nada mais. O resultado é válido somente quando a assinatura corresponde ao conteúdo e o certificado corresponde pelo número de série e impressão digital, portanto um documento assinado por outra parte falha na verificação – o que o exemplo demonstra ao executar a verificação duas vezes, uma com o certificado correto e outra com o de outra pessoa.

Lado a Lado: Esperado vs. Real

A última linha é a que restringe o planejamento, e leva à parte honesta deste artigo.

O que Ainda Não Funciona

Dois limites, ambos importantes de saber antes de prometer qualquer coisa.

A cobertura de formatos é apenas Word na 26.9 – DOCX, DOC, ODT e o restante da família Word. PDF, planilhas e apresentações não podem ser assinados com ML‑DSA. Para um pipeline que prioriza PDF, esta versão serve para prototipagem e medição, não para migração.

O suporte a validadores é o outro. Ainda não existe um identificador XML‑DSig padrão para ML‑DSA, portanto o Microsoft Word pode não relatar a assinatura como válida, embora ela seja criptograficamente correta e verificada corretamente via API. Isso é uma lacuna de padrões, não um defeito, e significa que a verificação deve estar no seu código, e não em um revisor que abre o arquivo e olha o banner.

Há também um detalhe de plataforma que não requer ação: .NET não pode ler chaves ML‑DSA em todos os lugares, incluindo Linux no .NET 8. Onde não consegue, o GroupDocs.Signature lê o certificado através do mecanismo Word, de modo que a mesma compilação funciona em um laptop de desenvolvedor e em um contêiner Linux sem código condicional.

Vale a pena fazer agora, dadas essas limitações?

Sim, por duas razões que não têm nada a ver com o código. A aquisição de certificados é lenta – as CAs públicas ainda estão lançando a emissão de ML‑DSA – então o trabalho do lado organizacional se beneficia de um início precoce. E “podemos produzir uma assinatura pós‑quântica hoje?” é uma pergunta que as equipes de conformidade começam a fazer; poder responder com um documento assinado em vez de um plano vale a tarde que isso leva.

O que o Exemplo Realmente Prova

Quatro métodos, executados em ordem, com o código de saída ligado ao resultado. Ele assina o contrato com ML‑DSA‑65 e imprime o assunto do certificado usado. Assina o mesmo contrato nos três níveis e imprime os tamanhos resultantes. Verifica o arquivo assinado duas vezes – uma com o certificado público do assinante, esperando sucesso, e outra com o certificado de outro assinante, esperando falha. Em seguida, lista as assinaturas digitais encontradas na saída.

A segunda verificação é a que vale a pena copiar. Uma rotina que só recebeu entradas válidas não informa nada sobre se rejeitaria uma entrada inválida, e para assinaturas essa é a questão completa.

Exemplo do Mundo Real: O Contrato de Trinta Anos

Arquivos de retenção longa são onde isso deixa de ser teórico. Um contrato assinado hoje e mantido por trinta anos precisa permanecer verificável independentemente do que acontecer com a criptografia nesse período, e “colher agora, descriptografar depois” é um modelo de ameaça documentado para exatamente esse tipo de material.

Para um arquivo assim, a medida prática hoje é de trilha dupla: manter RSA para os formatos que o ML‑DSA ainda não cobre, começar a assinar a saída Word com ML‑DSA‑65 ou 87, e registrar qual algoritmo foi usado por documento para que uma auditoria futura possa distingui‑los sem abrir os arquivos.

Uma Coisa a Corrigir no Exemplo Antes de Copiá-lo

O repositório fornece certificados ML‑DSA autoassinados para que a demonstração funcione imediatamente, o que significa quatro arquivos PFX e uma senha codificada em documents/. Para um certificado de teste descartável válido apenas dentro desse exemplo, isso está ok.

Isso não é um padrão a ser levado ao seu próprio repositório. Gere certificados de teste em tempo de execução, como faz o exemplo de validade de certificado do GroupDocs, ou mantenha‑os fora do controle de versão totalmente. Uma chave comprometida é difícil de revogar e tende a sobreviver à demonstração para a qual foi escrita.

Conclusão

As partes caras da migração pós‑quântica são certificados, políticas e validadores. O código, pelo menos para documentos Word em .NET, é um PFX diferente e a mesma chamada DigitalSignOptions. Clone o exemplo, aponte para um dos seus próprios contratos e você terá três arquivos assinados, dois resultados de verificação e uma comparação de tamanho em poucos minutos – o que é uma base melhor para um plano de migração do que uma estimativa.

Recursos Adicionais

• Projeto de exemplo completo em .NET no GitHub
• Guia passo a passo de caso de uso
• Assinar Documento com Assinatura Digital
• Verificar Assinaturas Digitais no Documento
• Documentação do GroupDocs.Signature para .NET
• Fórum de suporte gratuito