Ed25519 vs Ed448 : EdDSA à 128 ou 224 bits

Ed25519 vs Ed448, c’est une question de marge. Tous deux appartiennent à la même famille d’algorithmes, définie par la RFC 8032, tous deux sont approuvés par FIPS 186-5, et tous deux signent de façon déterministe, sans aucun aléa propre à chaque signature. Ed448 utilise une courbe plus grande pour atteindre environ 224 bits de sécurité classique au lieu d’environ 128, et le paie en taille, en vitesse et en prise en charge par l’écosystème.

Vue d’ensemble

Les vitesses ont été mesurées sur un cœur d’un Apple M4 Max avec openssl speed.

Marge de sécurité

Tous deux sont des variantes d’EdDSA sur des courbes d’Edwards, avec des formules d’addition complètes, des nonces déterministes et des encodages stricts : ils offrent donc la même robustesse face aux erreurs d’implémentation. La différence tient à la taille du groupe. Le groupe d’Ed25519, d’environ 2²⁵² éléments, donne environ 128 bits de sécurité face à l’algorithme rho de Pollard, soit le même niveau que P-256, AES-128 et la recherche de collisions sur SHA-256. Celui d’Ed448, d’environ 2⁴⁴⁶ éléments, donne environ 224 bits, plus que P-384 (192) et presque autant que P-521.

Pour un attaquant classique, 128 bits restent très largement hors de portée : la marge supplémentaire couvre donc le risque de progrès inattendus en cryptanalyse des courbes elliptiques plutôt que celui d’une recherche exhaustive. Face à un ordinateur quantique de grande taille, les deux courbes sont cassées par l’algorithme de Shor, pour un surcoût modeste dans le cas de la plus grande, ce qui explique pourquoi les plans post-quantiques du NIST les traitent de la même façon.

Différences de conception

Ed448 n’est pas une copie d’Ed25519 à plus grande échelle. Il hache avec SHAKE256 au lieu de SHA-512, ce qui ajoute une autre fonction de hachage à votre arbre de dépendances, et il place toujours en tête une chaîne de domaine comportant un contexte d’au plus 255 octets. Ed25519 n’a pas de contexte dans sa forme pure ; Ed25519ctx existe, mais il est rarement implémenté. Si votre protocole a besoin d’une séparation de domaines entre plusieurs usages d’une même clé, Ed448 la fournit d’office, alors qu’avec Ed25519 vous devez intégrer cette séparation au message signé.

Tous deux ont des variantes à pré-hachage, Ed25519ph et Ed448ph (HashEdDSA dans FIPS 186-5 §7.8), qui sont des algorithmes distincts aux signatures incompatibles ; utilisez les versions pures, sauf si vous devez signer des données que vous ne pouvez pas traiter d’un seul bloc.

Le script ci-dessous, exécuté avec Node.js 26.10 (OpenSSL 3.6.5), montre la différence de taille.

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

Prise en charge par l’écosystème

Ed25519 est largement disponible : OpenSSH (type de clé par défaut depuis la version 9.5), la bibliothèque standard de Go, libsodium, BoringSSL, Java 15 et versions ultérieures, .NET via des bibliothèques, toutes les grandes bibliothèques JOSE, les clés OpenPGP v6, Apple CryptoKit, WebCrypto dans tous les navigateurs actuels, et de nombreuses clés de sécurité pour SSH et FIDO2.

Ed448 est disponible dans OpenSSL, Bouncy Castle, Java 15 et versions ultérieures, Node.js, la bibliothèque cryptography de Python, certaines implémentations d’OpenPGP conformes à la RFC 9580 (où il est facultatif) et quelques bibliothèques JOSE. Il est absent d’OpenSSH, de la bibliothèque standard de Go, de BoringSSL et de WebCrypto dans les navigateurs (la liste des algorithmes de sign() sur MDN inclut Ed25519, mais pas Ed448). Aucune des deux courbes n’est autorisée dans les certificats TLS de confiance publique, dont les clés sont limitées à RSA et aux courbes du NIST.

Quand choisir l’un ou l’autre

• SSH, signature Git, versions logicielles, JWT, authentification de service à service : Ed25519.
• Signature côté navigateur avec WebCrypto : Ed25519 (ou ECDSA P-256 pour les navigateurs plus anciens) ; Ed448 n’est pas disponible.
• Politique exigeant au moins 192 bits de sécurité classique pour les signatures : Ed448, ou P-384 ou P-521 si la politique repose sur les courbes du NIST (par exemple, CNSA 1.0 désignait P-384, et non Ed448).
• Protocoles qui ont besoin d’une séparation de domaines intégrée : le contexte obligatoire d’Ed448 y aide ; avec Ed25519, incluez une étiquette fixe dans les données signées.
• Liaisons ou stockage très contraints : Ed25519, dont les signatures sont plus courtes de 50 octets et les clés de 25 octets.

Notes de migration

Passer de l’un à l’autre implique de nouvelles clés : les courbes, les fonctions de hachage et les identifiants diffèrent.

1. Contrôlez d’abord chaque vérificateur. La prise en charge d’Ed448 est le goulet d’étranglement : un seul consommateur qui repose sur la bibliothèque standard de Go ou sur OpenSSH suffit à l’exclure.
2. Changez explicitement les identifiants : OID 1.3.101.113, alg JOSE Ed448 (RFC 9864) ou EdDSA avec crv Ed448 pour les bibliothèques plus anciennes, COSE −53, algorithme OpenPGP 28 dans les clés v6.
3. Dimensionnez les tampons et les schémas pour des clés de 57 octets et des signatures de 114 octets ; les champs fixes de 32 et de 64 octets sont ce qui casse le plus souvent.
4. Fixez les contextes. Si vous adoptez Ed448, définissez la chaîne de contexte qu’utilise votre protocole, car le signataire et le vérificateur doivent transmettre la même.
5. Pour une protection à long terme, préférez un plan post-quantique (ML-DSA, éventuellement dans une signature composite avec Ed25519 ou Ed448) à un passage d’Ed25519 à Ed448.

Références

• RFC 8032, EdDSA (§5.1 Ed25519, §5.2 Ed448)
• FIPS 186-5, norme de signature numérique (§7)
• NIST SP 800-186 (§3.2.3.1 Edwards25519, §3.2.3.2 Edwards448)
• RFC 8410, Ed25519 et Ed448 dans X.509
• RFC 9864, algorithmes entièrement spécifiés pour JOSE et COSE
• RFC 9580, OpenPGP
• MDN : algorithmes pris en charge par SubtleCrypto.sign()