Ed25519 frente a Ed448: EdDSA de 128 o de 224 bits

Ed25519 frente a Ed448 es una cuestión de margen. Ambos pertenecen a la misma familia de algoritmos del RFC 8032, ambos están aprobados en FIPS 186-5 y ambos firman de forma determinista, sin aleatoriedad en cada firma. Ed448 funciona sobre una curva mayor para obtener unos 224 bits de seguridad clásica en lugar de unos 128, y lo paga en tamaño, en velocidad y en compatibilidad dentro del ecosistema.

De un vistazo

Las velocidades se midieron en un núcleo de un Apple M4 Max con openssl speed.

Margen de seguridad

Ambos son EdDSA sobre curvas de Edwards con fórmulas de suma completas, nonces deterministas y codificaciones estrictas, así que comparten la misma robustez frente a los errores de implementación. La diferencia está en el tamaño del grupo. El grupo de Ed25519, de unos 2²⁵² elementos, da unos 128 bits de seguridad frente al algoritmo rho de Pollard, el mismo nivel que P-256, AES-128 y las colisiones de SHA-256. El grupo de Ed448, de unos 2⁴⁴⁶ elementos, da unos 224 bits: más que P-384 (192) y cerca de P-521.

Para un atacante clásico, 128 bits quedan muy fuera de su alcance, así que el margen adicional protege frente a avances inesperados en el criptoanálisis de curvas elípticas, no frente a la fuerza bruta. Ante una computadora cuántica de gran tamaño, ambas curvas caen con el algoritmo de Shor, con un coste adicional modesto en el caso de la mayor, y por eso los planes poscuánticos del NIST las tratan igual.

Diferencias de diseño

Ed448 no es una copia a mayor escala. Calcula el hash con SHAKE256 en lugar de SHA-512, lo que supone otra función hash en tu árbol de dependencias, y siempre antepone una cadena de dominio con un contexto de hasta 255 bytes. Ed25519 no tiene contexto en su forma pura; Ed25519ctx existe, pero rara vez se implementa. Si tu protocolo necesita separación de dominios entre distintos usos de una misma clave, Ed448 la ofrece sin coste, mientras que con Ed25519 tienes que incluir esa separación en el mensaje firmado.

Ambos tienen variantes pre-hash, Ed25519ph y Ed448ph (HashEdDSA en FIPS 186-5 §7.8), que son algoritmos distintos con firmas incompatibles; usa las versiones puras salvo que tengas que firmar datos que no puedes procesar de una sola vez.

El script siguiente, ejecutado con Node.js 26.10 (OpenSSL 3.6.5), muestra la diferencia de tamaño.

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

Compatibilidad en el ecosistema

Ed25519 está ampliamente disponible: OpenSSH (el tipo de clave predeterminado desde la versión 9.5), la biblioteca estándar de Go, libsodium, BoringSSL, Java 15 y posteriores, .NET mediante bibliotecas, todas las bibliotecas JOSE importantes, las claves OpenPGP v6, Apple CryptoKit, WebCrypto en todos los navegadores actuales y muchas llaves de seguridad para SSH y FIDO2.

Ed448 está disponible en OpenSSL, Bouncy Castle, Java 15 y posteriores, Node.js, cryptography de Python, algunas implementaciones de OpenPGP según el RFC 9580 (donde es opcional) y algunas bibliotecas JOSE. No está en OpenSSH, en la biblioteca estándar de Go, en BoringSSL ni en el WebCrypto de los navegadores (la lista de algoritmos de sign() de MDN incluye Ed25519, pero no Ed448). Ninguna de las dos curvas se permite en los certificados TLS de confianza pública, cuyas claves se limitan a RSA y a las curvas del NIST.

Cuándo elegir cada uno

• SSH, firma de Git, publicación de versiones de software, JWT, autenticación entre servicios: Ed25519.
• Firma en el navegador con WebCrypto: Ed25519 (o ECDSA P-256 para navegadores antiguos); Ed448 no está disponible.
• Una política que exige al menos 192 bits de seguridad clásica para las firmas: Ed448, o P-384 o P-521 si la política se basa en las curvas del NIST (por ejemplo, CNSA 1.0 especificaba P-384, no Ed448).
• Protocolos que necesitan separación de dominios integrada: el contexto obligatorio de Ed448 ayuda; con Ed25519, incluye una etiqueta fija en los datos firmados.
• Enlaces o almacenamiento muy limitados: Ed25519, ya que sus firmas son 50 bytes más cortas y sus claves, 25 bytes más cortas.

Notas de migración

Pasar de uno a otro implica claves nuevas: son curvas distintas, hashes distintos e identificadores distintos.

1. Comprueba primero todos los verificadores. La compatibilidad con Ed448 es el cuello de botella; basta un solo consumidor que use la biblioteca estándar de Go u OpenSSH para descartarlo.
2. Cambia los identificadores de forma explícita: OID 1.3.101.113, alg de JOSE Ed448 (RFC 9864) o EdDSA con crv Ed448 en las bibliotecas más antiguas, COSE −53, algoritmo 28 de OpenPGP en las claves v6.
3. Dimensiona los búferes y los esquemas para claves de 57 bytes y firmas de 114 bytes; los campos fijos de 32 y 64 bytes son la causa clásica de fallos.
4. Decide qué hacer con los contextos. Si adoptas Ed448, define la cadena de contexto que usa tu protocolo, porque el firmante y el verificador deben pasar la misma.
5. Para una protección a largo plazo, prefiere un plan poscuántico (ML-DSA, posiblemente en una firma compuesta con Ed25519 o Ed448) antes que pasar de Ed25519 a Ed448.

Referencias

• RFC 8032, EdDSA (§5.1 Ed25519, §5.2 Ed448)
• FIPS 186-5, estándar de firma digital (§7)
• NIST SP 800-186 (§3.2.3.1 Edwards25519, §3.2.3.2 Edwards448)
• RFC 8410, Ed25519 y Ed448 en X.509
• RFC 9864, algoritmos totalmente especificados para JOSE y COSE
• RFC 9580, OpenPGP
• MDN: algoritmos admitidos por SubtleCrypto.sign()