Ed25519 vs Ed448: EdDSA de 128 ou de 224 bits

Ed25519 vs Ed448 é uma questão de margem. Os dois pertencem à mesma família de algoritmos da RFC 8032, os dois são aprovados pelo FIPS 186-5 e os dois assinam de forma determinística, sem aleatoriedade a cada assinatura. O Ed448 usa uma curva maior para chegar a cerca de 224 bits de segurança clássica em vez de cerca de 128, e paga por isso em tamanho, velocidade e suporte do ecossistema.

Visão geral

As velocidades foram medidas em um núcleo de um Apple M4 Max com openssl speed.

Margem de segurança

Os dois são EdDSA sobre curvas de Edwards, com fórmulas de adição completas, nonces determinísticos e codificações estritas, e por isso têm a mesma robustez contra erros de implementação. A diferença está no tamanho do grupo. O grupo do Ed25519, com cerca de 2²⁵² elementos, dá cerca de 128 bits de segurança contra o algoritmo rho de Pollard, o mesmo nível da P-256, do AES-128 e das colisões do SHA-256. O grupo do Ed448, com cerca de 2⁴⁴⁶ elementos, dá cerca de 224 bits, mais que a P-384 (192) e perto da P-521.

Para atacantes clássicos, 128 bits estão muito além do alcance, então a margem extra protege contra avanços inesperados na criptoanálise de curvas elípticas, e não contra a força bruta. Diante de um computador quântico de grande porte, as duas curvas sucumbem ao algoritmo de Shor, com um custo adicional modesto para a maior, e é por isso que os planos pós-quânticos do NIST tratam as duas da mesma forma.

Diferenças de projeto

O Ed448 não é uma cópia ampliada. Ele calcula o hash com SHAKE256 em vez de SHA-512, o que significa outra função de hash na sua árvore de dependências, e sempre insere como prefixo uma string de domínio com um contexto de até 255 bytes. O Ed25519 não tem contexto na forma pura; o Ed25519ctx existe, mas raramente é implementado. Se o seu protocolo precisa de separação de domínio entre usos diferentes de uma mesma chave, o Ed448 a oferece de graça; com o Ed25519, você precisa colocar a separação dentro da mensagem assinada.

Os dois têm variantes com pré-hash, Ed25519ph e Ed448ph (HashEdDSA no FIPS 186-5 §7.8), que são algoritmos separados, com assinaturas incompatíveis; use as versões puras, a menos que você precise assinar dados que não podem ser passados inteiros de uma só vez.

O script abaixo, executado com o Node.js 26.10 (OpenSSL 3.6.5), mostra a diferença de tamanho.

import { generateKeyPairSync, sign, verify } from "node:crypto";

const message = Buffer.from("release-2026.10.tar.gz digest");

for (const type of ["ed25519", "ed448"]) {
  const { privateKey, publicKey } = generateKeyPairSync(type);
  const signature = sign(null, message, privateKey);
  const raw = publicKey.export({ format: "jwk" }).x;
  console.log(
    type.padEnd(8),
    "public key:", Buffer.from(raw, "base64url").length, "bytes,",
    "SPKI DER:", publicKey.export({ type: "spki", format: "der" }).length, "bytes,",
    "signature:", signature.length, "bytes,",
    "verifies:", verify(null, message, publicKey, signature),
  );
}

ed25519  public key: 32 bytes, SPKI DER: 44 bytes, signature: 64 bytes, verifies: true
ed448    public key: 57 bytes, SPKI DER: 69 bytes, signature: 114 bytes, verifies: true

Suporte no ecossistema

O Ed25519 está amplamente disponível: no OpenSSH (o tipo de chave padrão desde a versão 9.5), na biblioteca padrão do Go, na libsodium, na BoringSSL, no Java 15 e versões posteriores, no .NET por meio de bibliotecas, em todas as principais bibliotecas JOSE, nas chaves OpenPGP v6, no Apple CryptoKit, na WebCrypto de todos os navegadores atuais e em muitas chaves de segurança para SSH e FIDO2.

O Ed448 está disponível no OpenSSL, no Bouncy Castle, no Java 15 e versões posteriores, no Node.js, no cryptography do Python, em algumas implementações OpenPGP da RFC 9580 (em que o suporte a ele é opcional) e em algumas bibliotecas JOSE. Ele não existe no OpenSSH, na biblioteca padrão do Go, na BoringSSL nem na WebCrypto dos navegadores (a lista de algoritmos de sign() do MDN inclui o Ed25519, mas não o Ed448). Nenhuma das duas curvas é permitida em certificados TLS de confiança pública, cujas chaves se limitam a RSA e às curvas do NIST.

Quando escolher cada um

• SSH, assinatura no Git, releases de software, JWTs, autenticação entre serviços: Ed25519.
• Assinatura no navegador com WebCrypto: Ed25519 (ou ECDSA P-256 para navegadores mais antigos); o Ed448 não está disponível.
• Uma política que exige pelo menos 192 bits de segurança clássica para assinaturas: Ed448, ou P-384 ou P-521 se a política se baseia nas curvas do NIST (por exemplo, a CNSA 1.0 indicava a P-384, e não o Ed448).
• Protocolos que precisam de separação de domínio embutida: o contexto obrigatório do Ed448 ajuda; com o Ed25519, inclua um rótulo fixo nos dados assinados.
• Canais de comunicação ou armazenamento muito limitados: Ed25519, já que as assinaturas são 50 bytes menores e as chaves, 25 bytes menores.

Notas de migração

Passar de um para o outro exige chaves novas: são curvas diferentes, hashes diferentes e identificadores diferentes.

1. Confira todos os verificadores primeiro. O suporte ao Ed448 é o gargalo; um único consumidor que use a biblioteca padrão do Go ou o OpenSSH já o descarta.
2. Troque os identificadores de forma explícita: OID 1.3.101.113, alg JOSE Ed448 (RFC 9864) ou EdDSA com crv Ed448 para bibliotecas mais antigas, COSE −53, algoritmo OpenPGP 28 nas chaves v6.
3. Dimensione buffers e schemas para chaves de 57 bytes e assinaturas de 114 bytes; campos fixos de 32 e 64 bytes são a causa clássica de quebra.
4. Decida sobre os contextos. Se adotar o Ed448, defina a string de contexto que o seu protocolo usa, porque o signatário e o verificador precisam passar a mesma.
5. Para proteção a longo prazo, prefira um plano pós-quântico (ML-DSA, possivelmente em uma assinatura composta com o Ed25519 ou o Ed448) a trocar o Ed25519 pelo Ed448.

Referências

• RFC 8032, EdDSA (§5.1 Ed25519, §5.2 Ed448)
• FIPS 186-5, padrão de assinatura digital (§7)
• NIST SP 800-186 (§3.2.3.1 Edwards25519, §3.2.3.2 Edwards448)
• RFC 8410, Ed25519 e Ed448 no X.509
• RFC 9864, algoritmos totalmente especificados para JOSE e COSE
• RFC 9580, OpenPGP
• MDN: algoritmos aceitos por SubtleCrypto.sign()