Dois algoritmos, um só trabalho
As assinaturas RSA se baseiam em exponenciação modular com um módulo composto grande: a chave privada é derivada de dois primos secretos, e a dificuldade de fatorar o produto deles é o que mantém a chave privada em sigilo. Já o ECDSA (algoritmo de assinatura digital com curvas elípticas, padronizado no FIPS 186-5) trabalha no grupo de pontos de uma curva elíptica, em que o problema difícil é o logaritmo discreto em curvas elípticas.
A consequência prática de os problemas difíceis serem diferentes: os ataques à fatoração escalam melhor do que os ataques ao logaritmo discreto em curvas elípticas, então as chaves RSA precisam crescer muito mais depressa do que as chaves EC para manter a mesma margem de segurança. Esse fato, sozinho, explica a maior parte das diferenças de tamanho e de desempenho descritas a seguir.
Tamanho: chaves e assinaturas com a mesma força
A comparação de níveis de segurança do NIST (veja a SP 800-57, parte 1) coloca uma chave de curva elíptica de 256 bits na mesma classe de segurança de 128 bits que um módulo RSA de 3072 bits:
| Nível de segurança | Curva ECDSA | Chave pública EC | Assinatura EC | Módulo RSA | Assinatura RSA |
|---|---|---|---|---|---|
| 112 bits | P-224 | 57 B / 29 B* | 56 B bruta | 2048 bits | 256 B |
| 128 bits | P-256 | 65 B / 33 B* | 64 B bruta (~70–72 B em DER) | 3072 bits | 384 B |
| 192 bits | P-384 | 97 B / 49 B* | 96 B bruta | 7680 bits | 960 B |
| 256 bits | P-521 | 133 B / 67 B* | 132 B bruta | 15360 bits | 1920 B |
(*codificação do ponto não comprimido / do ponto comprimido.) No nível de 128 bits — o mínimo para sistemas novos hoje —, uma assinatura ECDSA P-256 tem 64 bytes, contra os 384 bytes do RSA-3072, e a chave pública tem cerca de um décimo do tamanho. Mesmo o RSA-2048, amplamente implantado (e com margem menor), produz assinaturas de 256 bytes. Onde cada byte conta — certificados em um handshake TLS, tokens em um cabeçalho HTTP, transações em uma blockchain —, as curvas elípticas vencem em tamanho, sempre.
Repare nos dois números da assinatura ECDSA: 64 bytes no formato “bruto” contra ~70–72 bytes na codificação DER. A mesma assinatura matemática tem duas codificações comuns de transmissão, e confundi-las é uma das causas mais frequentes de erros “invalid signature”. Esse assunto tem um artigo próprio.
Velocidade: a assimetria entre assinar e verificar
Os dois algoritmos têm perfis de desempenho opostos, e vale a pena internalizar essa assimetria, porque ela decide arquiteturas reais:
- A verificação RSA é muito rápida. Verificar significa fazer uma exponenciação modular com o expoente público, que quase sempre é o valor pequeno 65537. É por isso que o RSA se manteve por tanto tempo nas cadeias de certificados: um certificado é assinado uma vez e verificado bilhões de vezes.
- Assinar com RSA é lento, porque a operação faz a exponenciação com o expoente privado de tamanho integral sobre um módulo de 2048 a 4096 bits. Gerar chaves RSA é mais lento ainda — é preciso procurar primos aleatórios grandes, o que pode levar frações perceptíveis de segundo e varia de forma imprevisível.
- Assinar com ECDSA é rápido — uma multiplicação escalar sobre um campo de 256 bits, em geral de várias vezes a uma ordem de grandeza mais rápida do que uma assinatura RSA-2048, com uma diferença muito maior em relação ao RSA-3072. Gerar uma chave EC sai praticamente de graça (uma multiplicação escalar), o que importa para chaves efêmeras e chaves por dispositivo.
- A verificação ECDSA é mais lenta do que a verificação RSA (cerca de duas multiplicações escalares), embora continue rápida em termos absolutos no hardware moderno.
A diferença de tamanho aparece diretamente em poucas linhas de Node.js:
import { generateKeyPairSync, sign } from "node:crypto";
const message = Buffer.from("measure me");
const ec = generateKeyPairSync("ec", { namedCurve: "P-256" });
const rsa = generateKeyPairSync("rsa", { modulusLength: 3072 }); // slow: prime search
const ecSig = sign("sha256", message, ec.privateKey); // DER-encoded by default
const rsaSig = sign("sha256", message, rsa.privateKey);
console.log("ECDSA P-256:", ecSig.length, "bytes"); // ~70-72 (64 raw)
console.log("RSA-3072: ", rsaSig.length, "bytes"); // 384
Onde cada um é usado hoje
- TLS / X.509. Os dois estão em toda parte. O RSA ainda domina a base instalada de certificados, mas os certificados ECDSA (P-256, P-384) fazem parte da oferta padrão das principais CAs e reduzem os handshakes de maneira significativa; muitos sites grandes servem ECDSA com RSA como alternativa. O TLS 1.3 oferece suporte nativo às duas famílias de assinatura.
- SSH. O ecossistema migrou para as curvas elípticas: o Ed25519 (um esquema de assinatura EC relacionado, mas que não é ECDSA) é o padrão habitual para chaves novas, e o ECDSA P-256 também é comum. Chaves RSA ainda funcionam, mas o esquema de assinatura legado
ssh-rsa(baseado em SHA-1) vem desativado por padrão nas versões recentes do OpenSSH — as chaves RSA precisam usar as variantes SHA-2. - JWTs. O RS256 (RSA) é o padrão histórico do ecossistema de identidade; o ES256 (ECDSA P-256) é a opção moderna e compacta, exigida por várias plataformas (as APIs de token da Apple, o DPoP, a maioria das credenciais WebAuthn e de chaves de acesso, ou passkeys). Os prós e contras são específicos a ponto de termos escrito um guia dedicado: ES256 vs RS256 em JWTs. Você pode inspecionar tokens reais no depurador de JWT.
- Blockchains. Território praticamente exclusivo do ECDSA: o Bitcoin e o Ethereum assinam com ECDSA sobre a curva secp256k1 (o Bitcoin adotou também assinaturas Schnorr com o Taproot). Os tamanhos de assinatura do RSA o descartam de saída onde cada byte de transação é pago.
- Assinatura de código e firmware. Historicamente com forte predomínio do RSA, hoje um cenário cada vez mais misto; dispositivos com recursos limitados preferem o ECDSA pelas chaves pequenas e pela assinatura rápida e econômica em memória.
O ponto fraco do ECDSA: o nonce precisa ser perfeito
O ECDSA tem um requisito operacional que o RSA simplesmente não tem: cada assinatura consome um número secreto novo, k (o nonce), e a segurança do esquema depende de esse número ser único e uniformemente aleatório em cada uma das assinaturas. Os modos de falha não perdoam:
- Se o mesmo
kfor usado alguma vez para duas mensagens diferentes com a mesma chave, a chave privada pode ser calculada a partir das duas assinaturas com álgebra elementar. Foi exatamente o que aconteceu no famoso incidente do PlayStation 3, em 2010, em que um nonce constante expôs a chave de assinatura do console. - Mesmo um nonce parcialmente previsível ou levemente enviesado, observado em muitas assinaturas, pode bastar para reconstruir a chave com técnicas baseadas em reticulados. Um gerador de números aleatórios fraco no sistema, no momento da assinatura, é, portanto, um risco de comprometimento da chave, e não apenas um problema de qualidade.
A resposta padrão é o ECDSA determinístico, especificado na RFC 6979: derivar k da chave privada e do hash da mensagem via HMAC, de modo que a mesma entrada sempre produza o mesmo nonce, bem distribuído, sem precisar de aleatoriedade no momento da assinatura. O FIPS 186-5 agora permite o ECDSA determinístico, e a maioria das bibliotecas modernas implementa a RFC 6979 ou uma variante hedged (derivação determinística misturada com entropia extra). Ao escolher uma biblioteca, essa é uma das primeiras coisas a verificar. O RSA, por outro lado, não precisa de aleatoriedade por assinatura no PKCS#1 v1.5, e o salt aleatório do RSA-PSS não compromete a chave se for repetido.
O relógio pós-quântico está correndo para os dois
Seja qual for a escolha, planeje a aposentadoria dela. Um computador quântico grande o suficiente, rodando o algoritmo de Shor, quebra tanto a fatoração quanto o logaritmo discreto em curvas elípticas — RSA e ECDSA caem juntos. O NIST esboçou o cronograma de transição no NIST IR 8547 (ainda um rascunho público inicial): os algoritmos de assinatura clássicos — ECDSA, EdDSA e RSA — ficam proibidos após 2035 para uso no governo federal dos EUA, em todos os conjuntos de parâmetros. Um marco anterior se aplica apenas ao nível de segurança de 112 bits, que, para assinaturas, significa RSA-2048 e P-224: esses ficam descontinuados após 2030, ou seja, ainda podem ser usados, mas com risco reconhecido. P-256, P-384 e RSA-3072 não são afetados pela data de 2030 — uma distinção que vale a pena acertar, porque muda quais das suas chaves precisam de atenção primeiro.
Os sucessores designados são o ML-DSA (baseado em reticulados, padronizado no FIPS 204) e o SLH-DSA (baseado em hash, FIPS 205), e o FN-DSA, derivado do Falcon, vem em seguida. Prepare-se para um choque de tamanho: uma assinatura ML-DSA-65 tem cerca de 3,3 KB — cinquenta vezes uma assinatura P-256 —, e é por isso que o trabalho nos protocolos para certificados híbridos e compostos ainda está em andamento. A lição prática para hoje não é “adote PQC em todo lugar agora”, e sim construa agilidade criptográfica: conheça todos os pontos em que seus sistemas assinam, mantenha as escolhas de algoritmo configuráveis e evite fixar no código tamanhos de chave ou de assinatura.
Então, qual usar hoje?
Quer ver as diferenças com bytes reais? Gere ou cole uma assinatura no verificador de assinatura ECDSA — ele detecta automaticamente a curva e a codificação e mostra exatamente o que verificou.