Ed25519 или Ed448: EdDSA со стойкостью 128 или 224 бита

Выбор между Ed25519 и Ed448 — вопрос запаса стойкости. Обе схемы относятся к одному семейству алгоритмов из RFC 8032, обе одобрены в FIPS 186-5 и обе подписывают детерминированно, без случайных данных для каждой подписи. Ed448 работает на кривой большего размера и даёт около 224 бит классической стойкости вместо примерно 128, а расплачивается за это размером, скоростью и поддержкой в экосистеме.

Коротко о главном

Скорость измерялась на одном ядре Apple M4 Max с помощью openssl speed.

Запас стойкости

Обе схемы — EdDSA на кривых Эдвардса с полными формулами сложения, детерминированными nonce и строгими кодировками, поэтому они одинаково устойчивы к ошибкам реализации. Различаются они размером группы. Группа Ed25519 из примерно 2²⁵² элементов даёт около 128 бит стойкости против ро-метода Полларда — тот же уровень, что у P-256, AES-128 и у поиска коллизий SHA-256. Группа Ed448 из примерно 2⁴⁴⁶ элементов даёт около 224 бит: больше, чем P-384 (192), и близко к P-521.

Для классического атакующего 128 бит далеко за пределами досягаемости, поэтому дополнительный запас страхует не от полного перебора, а от неожиданных прорывов в криптоанализе эллиптических кривых. Против большого квантового компьютера не устоит ни одна из кривых: обе взламываются алгоритмом Шора, причём для более крупной это лишь немного дороже, поэтому в постквантовых планах NIST к ним относятся одинаково.

Различия в устройстве

Ed448 — не увеличенная копия Ed25519. Эта схема хеширует с помощью SHAKE256 вместо SHA-512, а значит, в дереве зависимостей появляется другая хеш-функция. Кроме того, она всегда добавляет префикс — строку разделения доменов с контекстом длиной до 255 байт. В чистой форме у Ed25519 контекста нет; вариант Ed25519ctx существует, но реализуют его редко. Если протоколу нужно разделение доменов между разными применениями одного ключа, Ed448 обеспечивает его без дополнительной работы, а с Ed25519 разделение придётся заложить в само подписываемое сообщение.

У обеих схем есть варианты с предварительным хешированием, Ed25519ph и Ed448ph (HashEdDSA в FIPS 186-5, § 7.8). Это отдельные алгоритмы с несовместимыми подписями; используйте чистые варианты, если только вам не нужно подписывать данные, которые нельзя передать в функцию подписи целиком.

Скрипт ниже, запущенный на Node.js 26.10 (OpenSSL 3.6.5), показывает разницу в размерах.

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

Поддержка в экосистеме

Ed25519 поддерживается очень широко: OpenSSH (тип ключа по умолчанию начиная с версии 9.5), стандартная библиотека Go, libsodium, BoringSSL, Java 15 и новее, .NET через библиотеки, все основные библиотеки JOSE, ключи OpenPGP v6, Apple CryptoKit, WebCrypto во всех современных браузерах и многие ключи безопасности для SSH и FIDO2.

Ed448 есть в OpenSSL, Bouncy Castle, Java 15 и новее, Node.js, библиотеке cryptography для Python, некоторых реализациях OpenPGP по RFC 9580 (где поддержка этой схемы необязательна) и некоторых библиотеках JOSE. В OpenSSH, стандартной библиотеке Go, BoringSSL и браузерном WebCrypto Ed448 нет (в списке алгоритмов sign() на MDN есть Ed25519, но нет Ed448). Ни одна из двух кривых не допускается в публично доверенных TLS-сертификатах: для ключей таких сертификатов разрешены только RSA и кривые NIST.

Что когда выбирать

• SSH, подпись в Git, релизы ПО, JWT, аутентификация между сервисами: Ed25519.
• Подпись в браузере через WebCrypto: Ed25519 (или ECDSA P-256 для старых браузеров); Ed448 там нет.
• Политика, которая требует для подписей классической стойкости не менее 192 бит: Ed448 или, если политика опирается на кривые NIST, P-384 либо P-521 (например, в CNSA 1.0 была указана P-384, а не Ed448).
• Протоколы, которым нужно встроенное разделение доменов: поможет обязательный контекст Ed448; с Ed25519 включайте фиксированную метку в подписываемые данные.
• Каналы связи или хранилища с жёсткими ограничениями: Ed25519, потому что подписи Ed25519 на 50 байт короче, а ключи — на 25 байт.

Заметки о миграции

Переход с одной схемы на другую означает новые ключи: у схем разные кривые, разные хеш-функции и разные идентификаторы.

1. Сначала выясните, что поддерживают все проверяющие стороны. Узкое место — поддержка Ed448: достаточно одного получателя на стандартной библиотеке Go или OpenSSH, чтобы от Ed448 пришлось отказаться.
2. Явно смените идентификаторы: OID 1.3.101.113, JOSE alg Ed448 (RFC 9864) или EdDSA с crv Ed448 для старых библиотек, COSE −53, алгоритм OpenPGP 28 в ключах v6.
3. Рассчитайте буферы и схемы данных на 57-байтные ключи и 114-байтные подписи; поля фиксированного размера в 32 и 64 байта — типичная причина поломок.
4. Определитесь с контекстами. Если переходите на Ed448, задайте строку контекста, которую использует ваш протокол: подписант и проверяющая сторона должны передавать одну и ту же строку.
5. Для долгосрочной защиты предпочтите постквантовый план (ML-DSA, возможно в составной подписи с Ed25519 или Ed448) переходу с Ed25519 на Ed448.

Источники

• RFC 8032, EdDSA (Ed25519 в § 5.1, Ed448 в § 5.2)
• FIPS 186-5, стандарт цифровой подписи (§ 7)
• NIST SP 800-186 (Edwards25519 в § 3.2.3.1, Edwards448 в § 3.2.3.2)
• RFC 8410, Ed25519 и Ed448 в X.509
• RFC 9864, полностью определённые алгоритмы для JOSE и COSE
• RFC 9580, OpenPGP
• MDN: алгоритмы, которые поддерживает SubtleCrypto.sign()