#!/intro
A criptografia pós-quântica representa uma resposta direta às ameaças que a computação quântica representa para criptografia clássica, dado que a sua capacidade de cálculo tem o potencial de comprometer os sistemas baseados em algoritmos como RSA, DSA ou curvas elípticas.
Para mitigar este risco, o NIST conduziu um longo processo de padronização de algoritmos resistentes a ataques quânticos, culminando na padronização dos novos standards como os ML-KEM, ML-DSA e SLH-DSA (veja também Criptografia pós-quântica: os novos algoritmos).
Durante as fases preliminares desse processo, foi desenvolvido o projeto oqs-provider, um módulo experimental para OpenSSL, criado por Michael Baentsch e posteriormente integrado no projeto Open Quantum Safe (OQS). O oqs-provider possibilitou a adoção de esquemas pós-quânticos como Kyber, Dilithium e SPHINCS+ antes da sua padronização formal, permitindo validar a sua viabilidade técnica e identificar desafios práticos de interoperabilidade em ambientes de produção.
Com o lançamento da versão 3.5.0, o OpenSSL passou a suportar nativamente, sem dependências externas, os algoritmos recentemente padronizados, permitindo a sua utilização em operações de assinatura, verificação, troca de chaves e encapsulamento de segredos.
> suporte
Os três esquemas pós-quânticos atualmente suportados são:
O ML-KEM, definido no FIPS 203, destina-se à troca de chaves e implementa um mecanismo de encapsulamento de segredos com resistência quântica. Surge como alternativa moderna a esquemas clássicos como o ECDH, oferecendo robustez criptográfica sem comprometer a eficiência.
O ML-DSA, especificado no FIPS 204, executa operações de assinatura digital com elevado desempenho e propriedades de segurança adequadas a contextos generalistas, sendo particularmente eficiente na geração e verificação de assinaturas.
O SLH-DSA, formalizado no FIPS 205, é um esquema de assinatura baseado exclusivamente em funções dispersão criptográfica totalmente stateless, eliminando a necessidade de manter estado entre operações. Apresenta variantes que equilibram desempenho e tamanho das assinaturas.
Todos estes esquemas estão disponíveis tanto no default provider como no FIPS provider do OpenSSL, podendo assim ser utilizados em ambientes regulamentados, sem necessidade de extensões externas ou bibliotecas adicionais.
A verificação do suporte deve começar pela confirmação da versão do OpenSSL instalada. Apenas a versão 3.5 ou superior disponibiliza estes esquemas de forma nativa.
Para verificar, utilize o comando version.
$ openssl version
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
Em seguida, certifique-se de que os providers necessários estão carregados. Utilize o comando list -providers para confirmar que o pelo menos o default provider ou o FIPS provider estão carregados.
$ openssl list -providers
Providers:
default
name: OpenSSL Default Provider
version: 3.5.0
status: active
Finalmente, confirme os algoritmos de chave pública suportados com o comando list -public-key-algorithms. A presença de entradas como ML-DSA-44, SLH-DSA-SHA2-128f ou ML-KEM-512 indica que o suporte para algoritmos pós-quânticos está corretamente instalado e funcional.
$ openssl list -public-key-algorithms
...
Name: OpenSSL ML-DSA-44 implementation
Type: Provider Algorithm
IDs: { 2.16.840.1.101.3.4.3.17, id-ml-dsa-44, ML-DSA-44, MLDSA44 } @ default
Name: OpenSSL ML-DSA-65 implementation
Type: Provider Algorithm
IDs: { 2.16.840.1.101.3.4.3.18, id-ml-dsa-65, ML-DSA-65, MLDSA65 } @ default
Name: OpenSSL ML-DSA-87 implementation
Type: Provider Algorithm
IDs: { 2.16.840.1.101.3.4.3.19, id-ml-dsa-87, ML-DSA-87, MLDSA87 } @ default
...
> chaves
A geração de chaves é feita com o comando genpkey, utilizando o identificador do algoritmo tal como aparece na saída do comando list -public-key-algorithms. Esta correspondência é obrigatória para que o comando seja interpretado corretamente e o contexto de geração seja inicializado com sucesso.
As chaves são geradas no formato PKCS#8 e codificadas em PEM. Estas estruturas incluem todos os parâmetros necessários, como a chave pública, privada e, quando aplicável, uma semente para regeneração determinística.
>> ML-DSA
openssl genpkey -algorithm ML-DSA-44 -out mldsa_priv.pem
As variantes disponíveis são ML-DSA-44, ML-DSA-65 e ML-DSA-87, correspondendo aproximadamente a níveis de segurança de 128, 192 e 256 bits, respetivamente. Cada uma define um conjunto distinto de parâmetros que afetam diretamente o tamanho das chaves, das assinaturas e o desempenho das operações.
>> SLH-DSA
openssl genpkey -algorithm SLH-DSA-SHA2-128f -out slhdsa_priv.pem
Outras variantes incluem SLH-DSA-SHA2-128s, SLH-DSA-SHA2-192f, SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-192f e SLH-DSA-SHAKE-256s, entre outras. O prefixo SHA2 ou SHAKE indica a função de dispersão criptográfica utilizada, sendo SHA2 correspondente à família SHA-2, como SHA-256, e SHAKE referente às variantes de saída extensível do conjunto SHA-3. O número 128, 192 ou 256 define o nível de segurança em bits, de acordo com o FIPS 205. Os sufixos s e f identificam o modo simple, que gera assinaturas mais compactas, e o modo fast, que privilegia o desempenho à custa de um maior tamanho de assinatura.
>> ML-KEM
openssl genpkey -algorithm ML-KEM-512 -out mlkem_priv.pem
As variantes disponíveis são ML-KEM-512, ML-KEM-768 e ML-KEM-1024, correspondendo a níveis de segurança aproximados de 128, 192 e 256 bits, respetivamente. Cada uma apresenta diferenças nos parâmetros internos, nos tamanhos das chaves pública e privada, e no tamanho do encapsulamento gerado durante o processo de troca de segredo.
> chave_publica
A extração da chave pública a partir de uma chave privada é realizada com o comando:
openssl pkey -in chave_privada.pem -pubout -out chave_publica.pem
A chave pública resultante é codificada em PEM e segue o formato X.509 SubjectPublicKeyInfo.
> operacoes_criptograficas
As operações suportadas pelos algoritmos pós-quânticos no OpenSSL incluem assinatura, verificação, encapsulamento e decapsulamento de segredos. Estas funcionalidades são disponibilizadas através da ferramenta de linha de comando pkeyutl, utilizando os mesmos fluxos das primitivas clássicas, mas com suporte nativo para os novos algoritmos.
Assinatura e verificação:
As operações de assinatura e verificação com ML-DSA ou SLH-DSA seguem o modelo tradicional suportado pelo OpenSSL. A assinatura é realizada com uma chave privada, e a verificação com a chave pública correspondente. Os dados assinados não são cifrados, apenas autenticados.
Para assinar um ficheiro com a chave privada:
openssl pkeyutl -sign -inkey chave_privada.pem \
-in mensagem.txt \
-out assinatura.bin
Para verificar a assinatura com a chave pública:
openssl pkeyutl -verify -pubin -inkey chave_publica.pem \
-in mensagem.txt \
-sigfile assinatura.bin
Signature Verified Successfully
O conteúdo da assinatura é binário e depende do algoritmo e da variante utilizados. Recomenda-se, quando necessário, a sua codificação, por exemplo em base64, para facilitar o transporte ou o armazenamento.
Encapsulamento e decapsulamento:
O algoritmo ML-KEM implementa um mecanismo de encapsulamento de chave simétrica, permitindo o estabelecimento de um segredo partilhado entre duas partes sem necessidade de troca prévia de informação sensível.
No processo, o remetente utiliza a chave pública do destinatário para gerar um segredo partilhado e um encapsulamento correspondente. O destinatário, por sua vez, utiliza a sua chave privada para recuperar o mesmo segredo a partir do encapsulamento.
Encapsular um segredo com a chave pública do destinatário:
openssl pkeyutl -encap -pubin -inkey chave_publica.pem \
-out encapsulado.bin \
-secret segredo.bin
Decapsular o segredo com a chave privada:
openssl pkeyutl -decap -inkey chave_privada.pem \
-in encapsulado.bin \
-secret segredo_recuperado.bin
O ficheiro segredo.bin contém a chave partilhada gerada pelo remetente. O ficheiro encapsulado.bin, que contém os dados necessários para a recuperação do segredo partilhado, pode ser transmitido em claro, dado que não revela o conteúdo do segredo e não permite a sua reconstrução sem a chave privada correspondente. Após o decapsulamento, o destinatário obtém a mesma chave em segredo_recuperado.bin.
> consideracoes
A adoção de algoritmos pós-quânticos no OpenSSL exige atenção a vários aspetos operacionais. Os tamanhos das chaves e assinaturas são significativamente superiores aos dos algoritmos clássicos, o que pode afetar o desempenho em redes com largura de banda reduzida ou em sistemas com restrições de armazenamento. No caso do SLH-DSA, as assinaturas podem atingir vários kilobytes, o que pode impactar protocolos que não tenham sido concebidos para estruturas tão extensas.
Em termos de desempenho, ML-DSA oferece tempos de assinatura e verificação competitivos, sendo adequado para aplicações interativas. SLH-DSA, embora mais versátil em termos de segurança estrutural, é mais exigente computacionalmente. Já o ML-KEM apresenta desempenho robusto tanto na geração como na recuperação do segredo partilhado, com tempos estáveis mesmo em variantes de segurança elevada.
Estes algoritmos utilizam formatos standard como PKCS#8 para chaves privadas e X.509 para chaves públicas, o que facilita a integração em ferramentas compatíveis com estruturas ASN.1. No entanto, ainda não são amplamente suportados por protocolos como TLS, SSH ou S/MIME sem alterações nos respetivos formatos de negociação ou extensões específicas.
> conclusão
A integração dos algoritmos pós-quânticos no OpenSSL 3.5 representa um avanço significativo na preparação para a migração para esquemas criptográficos resistentes a ataques de computadores quânticos. O suporte dos standards FIPS 203, 204 e 205 permite a sua utilização direta em contextos operacionais, com garantia de conformidade normativa e sem necessidade de bibliotecas externas.
Apesar do progresso técnico, a adoção destes algoritmos exige um planeamento cuidadoso. As diferenças em termos de tamanho de chaves e assinaturas podem afetar o desempenho, a compatibilidade e os mecanismos atuais de armazenamento e transmissão. A interoperabilidade com protocolos ainda não adaptados, como TLS ou S/MIME, impõe desafios adicionais que devem ser devidamente avaliados.
A transição para criptografia resistente a ataques quânticos deve ser sustentada por processos de experimentação, validação e análise de risco que assegurem uma adoção progressiva, segura e em conformidade com os requisitos técnicos e regulamentares de cada organização.
> status: resistant
> exit 0