S/MIME vs OpenPGP: assinatura e criptografia de e-mail

S/MIME vs OpenPGP é a escolha entre os dois padrões de segurança de ponta a ponta para e-mail. O S/MIME (RFC 8551) encapsula as mensagens na Cryptographic Message Syntax e identifica as pessoas com certificados X.509 emitidos por autoridades certificadoras. O OpenPGP (RFC 9580) usa um formato de pacotes próprio e chaves que os donos geram e publicam por conta própria, e a confiança se estabelece pela conferência de impressões digitais, por assinaturas de outros usuários ou pelo domínio do destinatário.

Visão geral

Como é uma assinatura

O script abaixo assina a mesma mensagem curta das duas formas, com o GnuPG 2.5.21 e o OpenSSL 3.6.5, e depois verifica cada assinatura. As chaves e a CA descartável são criadas em um diretório temporário e apagadas no final.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
export GNUPGHOME="$dir/gnupg"
mkdir -m 700 "$GNUPGHOME"
printf 'Quarterly report attached.\n' > msg.txt

echo "== OpenPGP (GnuPG)"
gpg --batch --quiet --passphrase '' --quick-gen-key "Alice <alice@example.org>" ed25519 sign 1d
gpg --batch --quiet --detach-sign msg.txt
gpg --batch --verify msg.txt.sig msg.txt 2>&1 | grep -E "using|Good"
echo "signature bytes: $(wc -c < msg.txt.sig)"
gpgconf --kill gpg-agent

echo "== S/MIME (OpenSSL CMS)"
EC="-newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc"
openssl req -x509 $EC -keyout ca.key -out ca.pem -days 30 -subj "/CN=Example Mail CA" \
  -addext "keyUsage=critical,keyCertSign" 2>/dev/null
openssl req -x509 $EC -CA ca.pem -CAkey ca.key -keyout alice.key -out alice.pem -days 30 \
  -subj "/CN=Alice" -addext "subjectAltName=email:alice@example.org" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=emailProtection" 2>/dev/null
openssl cms -sign -binary -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out msg.p7s
openssl cms -verify -binary -in msg.p7s -inform DER -content msg.txt -CAfile ca.pem -out /dev/null
echo "signature bytes: $(wc -c < msg.p7s)"
openssl cms -sign -binary -nocerts -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out bare.p7s
echo "without the embedded certificate: $(wc -c < bare.p7s)"
cd / && rm -rf "$dir"

== OpenPGP (GnuPG)
gpg:                using EDDSA key 57AE27428681EABC417A15B7DDA5B1FF5FAE8694
gpg: Good signature from "Alice <alice@example.org>" [ultimate]
signature bytes:      147
== S/MIME (OpenSSL CMS)
CMS Verification successful
signature bytes:      907
without the embedded certificate:      446

A diferença de tamanho é estrutural. Uma assinatura CMS normalmente leva o certificado do signatário, para que qualquer destinatário possa verificá-la com base em uma raiz confiável e guardar o certificado para criptografar as respostas; mesmo sem ele, atributos assinados, como o horário da assinatura e o tipo de conteúdo, deixam a estrutura maior. Uma assinatura desanexada do OpenPGP identifica a chave pela impressão digital, então o destinatário precisa já ter a chave ou buscá-la. A impressão digital de 40 caracteres mostra que o GnuPG criou uma chave da versão 4; as chaves da versão 6 da RFC 9580 usam impressões digitais SHA-256 de 64 caracteres.

Como cada um decide em quem confiar

O S/MIME delega a decisão às autoridades certificadoras. Desde 1º de setembro de 2023, os certificados S/MIME de confiança pública seguem os S/MIME Baseline Requirements do CA/Browser Forum: a CA precisa verificar o controle de cada endereço de e-mail, os tipos de certificado vão do mailbox-validated (validação da caixa de correio) ao individual-validated (validação da pessoa), os perfis “legacy”, mais permissivos, não podem mais ser emitidos desde 15 de julho de 2025, e os certificados de usuário final duram no máximo 825 dias. As empresas também podem operar a própria CA e implantar certificados pelo gerenciamento de dispositivos, que é como funciona a maioria das grandes implantações de S/MIME.

O OpenPGP deixa a decisão com os usuários. A rede de confiança original, em que os usuários assinam as chaves uns dos outros, nunca escalou além de comunidades pequenas, e os servidores de chaves públicos que aceitavam qualquer chave enviada se tornaram inutilizáveis para identidades não verificadas. A prática atual é comparar impressões digitais por um canal separado, aceitar uma chave no primeiro uso ou buscá-la em um Web Key Directory, onde o próprio domínio do destinatário fornece a chave por HTTPS. O keys.openpgp.org só publica identidades depois de verificar o endereço.

Clientes, compatibilidade e a divisão do OpenPGP

O ponto forte do S/MIME é a integração: o Outlook, o Apple Mail e o iOS Mail assinam e criptografam nativamente assim que um certificado é instalado, e o Gmail oferece S/MIME hospedado em algumas edições do Google Workspace. O OpenPGP é nativo no Thunderbird e no Proton Mail e está disponível em outros clientes por meio de complementos.

O OpenPGP também tem uma divisão nos padrões. A IETF publicou a RFC 9580 em julho de 2024, com chaves da versão 6, criptografia AEAD obrigatória e proteção da frase secreta com Argon2, e a RFC 9980 em junho de 2026, para chaves pós-quânticas. O GnuPG, por sua vez, implementa o LibrePGP, cujas chaves da versão 5 e cujo formato de pacote OCB diferem da RFC 9580. Chaves da versão 4 com o pacote clássico de dados criptografados funcionam em todas as implementações; o GnuPG pode passar a usar seu pacote OCB com destinatários cujas chaves anunciam suporte a ele, e recursos da RFC 9580, como as chaves da versão 6, precisam ser testados com o software dos seus correspondentes.

Os dois padrões foram afetados pelo EFAIL (2018), em que um texto cifrado manipulado fazia os clientes de e-mail vazarem o texto descriptografado por meio de HTML. As correções duradouras são a criptografia autenticada (AES-GCM no S/MIME 4.0, o código de detecção de modificação e agora o AEAD no OpenPGP) e clientes que se recusam a exibir texto claro que falha na autenticação.

Quando escolher cada um

• E-mail corporativo em dispositivos gerenciados: S/MIME com certificados implantados por MDM; deixe em custódia (escrow) as chaves de criptografia, nunca as chaves de assinatura.
• Parceiros externos que já têm certificados S/MIME (setor público, bancos, saúde): S/MIME.
• Indivíduos, jornalistas, mantenedores de código aberto: OpenPGP, com chaves publicadas via WKD ou keys.openpgp.org.
• Criptografar arquivos, backups ou segredos em vez de e-mail: nenhum dos dois; use o age (veja age vs GPG).
• Assinar versões de software e commits: o OpenPGP ainda funciona, mas o Sigstore e as assinaturas SSH costumam ser mais simples (veja Sigstore vs assinatura com GPG).
• Proteger a linha de assunto: seja qual for a escolha, use um cliente que implemente a proteção de cabeçalhos (RFC 9788); caso contrário, o assunto trafega em claro.

Notas de migração

1. Novas implantações de S/MIME: solicite certificados dos perfis strict ou multipurpose com o endereço no Subject Alternative Name e separe as chaves de assinatura das chaves de criptografia, para que só as últimas fiquem em custódia.
2. Usuários atuais de S/MIME: os certificados emitidos no perfil legacy estão sendo substituídos na renovação; confira se os clientes dos parceiros aceitam os novos perfis antes que seus certificados antigos expirem.
3. Chaves OpenPGP: gere chaves Ed25519 e X25519 (ou chaves da versão 6, onde o software de todos os seus correspondentes as aceitar), defina uma expiração de um a dois anos e prorrogue-a, guarde um certificado de revogação offline e publique as chaves via WKD.
4. E-mails arquivados: mantenha as chaves de descriptografia ou os certificados antigos enquanto precisar ler mensagens antigas; criptografar de novo as mensagens arquivadas é a única forma de aposentá-los.
5. Planejamento pós-quântico: e-mails criptografados estão expostos à estratégia coletar agora, descriptografar depois (harvest now, decrypt later). O ML-KEM está especificado para CMS (RFC 9936) e, combinado com X25519, para OpenPGP (RFC 9980); planeje primeiro as chaves de criptografia e depois as assinaturas. O inspetor de OpenPGP e o verificador de S/MIME mostram quais algoritmos uma chave, um certificado ou uma mensagem usa.

Referências

• RFC 8551, especificação de mensagens S/MIME 4.0
• RFC 5652, Cryptographic Message Syntax
• RFC 9580, OpenPGP
• RFC 9980, criptografia pós-quântica no OpenPGP
• RFC 9936, ML-KEM no CMS
• RFC 9788, proteção de cabeçalhos para e-mail com proteção criptográfica
• S/MIME Baseline Requirements do CA/Browser Forum (§6.1.5, §6.3.2, §7.1.6.1)
• OpenPGP Web Key Directory (Internet-Draft)
• EFAIL