Два мира эллиптических подписей: Ed25519 против ECDSA

Каждый раз, когда вы открываете сайт по HTTPS, отправляете биткоин-транзакцию, подключаетесь к серверу по SSH или пишете сообщение в Signal, где-то под капотом работает цифровая подпись. Она удостоверяет, что данные подлинные, что их не подменили по дороге и что отправитель — действительно тот, за кого себя выдаёт.

В мире эллиптических подписей два имени звучат чаще остальных: ECDSA и Ed25519. Первый — классический стандарт, который десятилетиями крутится внутри TLS, Bitcoin и корпоративной криптографии. Второй — алгоритм новой волны, который выбирают OpenSSH, WireGuard и десятки современных протоколов.

Чем они отличаются на самом деле? Не на уровне лозунга «Ed25519 моднее», а по сути — в математике, в архитектуре, в том, как легко допустить фатальную ошибку при реализации. Разберёмся шаг за шагом, от базовых принципов до конкретного кода.

Что такое цифровая подпись и зачем она нужна

Прежде чем сравнивать алгоритмы, стоит вспомнить, какую задачу они решают.

Цифровая подпись — это математический механизм, который даёт три гарантии:

• аутентичность — сообщение действительно пришло от владельца определённого ключа;
• целостность — содержимое не изменяли после подписания;
• неотказуемость — подписавший не может правдоподобно отрицать факт подписи.

Схема работает на паре ключей. Приватный ключ — секрет, который хранится только у вас. Публичный ключ — его можно раздавать всем, как номер банковского счёта. Вы подписываете сообщение приватным ключом, любой может проверить подпись по публичному — но сгенерировать новую подпись «как будто от вас» без приватного ключа не может.

Если провести аналогию с бумажным миром: цифровая подпись — это печать на документе, но такая, которую подделать на порядки сложнее, чем нарисовать похожую закорючку. И в отличие от рукописной подписи, любое изменение в документе после подписания немедленно обнаруживается.

Почему эллиптические кривые вытесняют RSA

Долгое время стандартом де-факто для цифровых подписей был RSA — алгоритм, предложенный Ривестом, Шамиром и Адлеманом в 1977 году. RSA опирается на сложность факторизации больших чисел: разложить произведение двух огромных простых чисел обратно на множители — задача, для которой не существует эффективного алгоритма.

RSA работает и по сей день, но у него есть фундаментальная проблема масштабирования. Чтобы обеспечить 128 бит безопасности (то есть уровень, при котором перебор всех вариантов потребует порядка 2^128 операций), RSA нужен ключ длиной 3072 бита. Это 384 байта только на публичный ключ, а подписи ещё длиннее. На слабом железе — смарт-картах, IoT-устройствах, мобильных телефонах — такие вычисления очень медленны.

Эллиптические кривые решают ту же задачу принципиально иначе. Вместо факторизации они опираются на задачу дискретного логарифма в группе точек эллиптической кривой (Elliptic Curve Discrete Logarithm Problem, ECDLP). Суть в том, что «умножить» точку на кривой на большое число легко, а вот восстановить это число по результату — вычислительно неподъёмно.

Главное преимущество: для тех же 128 бит безопасности эллиптической схеме достаточно 256-битного ключа — это 32 байта. В 12 раз короче, чем у RSA. Подписи тоже компактнее, а операции — быстрее.

Именно поэтому с начала 2000-х годов индустрия постепенно мигрирует с RSA на эллиптические схемы. Так появились два главных конкурента: ECDSA и Ed25519.

ECDSA: классический стандарт, рождённый в 90-х

Кто придумал и когда стандартизовали

Идея применить эллиптические кривые к цифровым подписям появилась в начале 1990-х. В 1992 году канадский криптограф Скотт Ванстоун (Scott Vanstone) предложил ECDSA — Elliptic Curve Digital Signature Algorithm — как эллиптический аналог классического DSA. Ванстоун — профессор математики Университета Ватерлоо и сооснователь компании Certicom — активно продвигал криптографию на эллиптических кривых в то время, когда большинство считало её экзотикой. Он верил, что компактные ключи и быстрые операции сделают эллиптические кривые стандартом индустрии, и оказался прав — хотя сам не дожил до полного триумфа (Ванстоун скончался в 2014 году).

Стоит отметить контекст появления ECDSA. DSA — его неэллиптический предшественник — был предложен NIST в 1991 году. Бернштейн позже укажет, что DSA по сути воспроизводит схему Эль-Гамаля 1985 года, игнорируя большинство улучшений Шнорра 1990 года. Патент Шнорра, истекший только в 2008 году, помешал NIST использовать более элегантную конструкцию. ECDSA унаследовал эту «генетику» — и часть связанных с ней архитектурных недостатков.

ECDSA прошёл долгий путь стандартизации: сначала стандарт ISO 14888-3 (1998) и ANSI X9.62 (1998), затем IEEE P1363 (2000), и наконец — включение в FIPS 186-2 от NIST в 2000 году. С этого момента ECDSA стал «официально одобренным» алгоритмом для государственных систем США и — по цепочке — для множества корпоративных и коммерческих продуктов по всему миру.

Кривые: P-256 и secp256k1

ECDSA — это не один конкретный алгоритм, а семейство. Конкретная реализация зависит от выбора эллиптической кривой и её параметров. Две самые распространённые:

• NIST P-256 (она же secp256r1, она же prime256v1) — стандартная кривая от NIST, повсеместно используемая в TLS/HTTPS и корпоративной инфраструктуре;
• secp256k1 — кривая, выбранная Сатоши Накамото для Bitcoin и унаследованная десятками блокчейнов.

Буква «r» в названии secp256r1 означает «random» — параметры кривой были сгенерированы с помощью случайного зерна. Буква «k» в secp256k1 означает «Koblitz» — параметры подобраны из соображений эффективности. Это важное различие, к которому мы вернёмся, когда будем говорить о доверии к параметрам.

Как работает ECDSA: интуиция

Упрощённо, ECDSA работает так:

Генерация ключей. Выбираем случайное большое число d — это приватный ключ. Умножаем его на заранее фиксированную «базовую точку» G на кривой и получаем точку Q = dG. Это публичный ключ. Операция умножения точки на число — быстрая. Обратная задача (по Q и G найти d) — вычислительно неподъёмная.

Подпись сообщения. Сначала вычисляем хеш сообщения h = H(m). Затем выбираем одноразовое случайное число k — так называемый nonce (number used once), секретное и уникальное для каждой подписи. Вычисляем точку R = kG, берём её x-координату как число r. Затем вычисляем второй компонент подписи: s = k^(-1)(h + rd) mod n, где n — порядок группы точек кривой. Пара (r, s) — это и есть подпись.

Проверка подписи. Зная публичный ключ Q, сообщение m и подпись (r, s), проверяющий восстанавливает определённую линейную комбинацию точек на кривой и сверяет x-координату результата с r. Если совпало — подпись корректна.

По существу, ECDSA-подпись — это компактное математическое доказательство того, что вы владеете приватным ключом, без раскрытия самого ключа.

Ахиллесова пята: случайный nonce

У ECDSA есть одно фундаментальное требование, нарушение которого катастрофично: каждая подпись должна использовать уникальный, случайный и секретный nonce k.

Почему это так опасно? Если одно и то же k используется для подписи двух разных сообщений, из двух пар (r, s) можно алгебраически восстановить приватный ключ. Математика здесь простая: имея два уравнения с одним и тем же неизвестным k, вы получаете систему, из которой k выражается тривиально, а из k немедленно вычисляется d.

Это не теоретический ужас, а реальные инциденты с многомиллионными последствиями.

Sony PlayStation 3, 2010 год. Группа хакеров fail0verflow обнаружила, что Sony подписывала обновления прошивки PS3 алгоритмом ECDSA, но при этом использовала одно и то же значение k для всех подписей. На конференции 27C3 они продемонстрировали извлечение приватного ключа Sony, что позволило подписывать произвольный код для запуска на консоли. Как выразился один из исследователей на презентации: Sony буквально «выбрала число 4 в качестве случайного» — отсылка к известному XKCD-комиксу о генераторах случайных чисел.

Android Bitcoin-кошельки, 2013 год. Реализация SecureRandom в Android содержала ошибку, из-за которой генератор случайных чисел в некоторых условиях выдавал повторяющиеся значения. Это привело к утечке приватных ключей из Bitcoin-кошельков и краже средств. Google выпустил экстренный патч, но пострадавшим это не помогло.

По сути, ECDSA говорит разработчику: «Алгоритм отличный, но вы обязаны идеально реализовать генерацию случайных чисел и ни разу не ошибиться». Для профессионального криптографа это приемлемо. Для обычного разработчика такие условия — мина замедленного действия.

«Стандартный выбор, ECDSA, вполне разумен — если вас не волнуют простота, скорость и безопасность».

— Даниэль Бернштейн, «How to design an elliptic-curve signature system», 2014

Ed25519: подписи, спроектированные с учётом чужих ошибок

Даниэль Бернштейн и философия Curve25519

В 2005 году профессор Даниэль Дж. Бернштейн (Daniel J. Bernstein, известный в криптографическом сообществе как djb) опубликовал спецификацию Curve25519 — эллиптической кривой, спроектированной с нуля для безопасности и производительности. Название отсылает к простому числу 2^255 - 19, которое определяет конечное поле кривой. Эта элегантная форма числа не случайна: она обеспечивает быструю модульную арифметику на стандартных 64-битных процессорах.

Бернштейн — фигура необычная для мира стандартов. Профессор математики, автор qmail, djbdns и множества криптографических библиотек, он давно и последовательно критикует подход NIST к выбору криптографических параметров. Его аргумент: параметры NIST-кривых (P-256 и других) были сгенерированы с использованием «случайного зерна», происхождение которого не до конца прозрачно. После разоблачений бэкдора в генераторе Dual_EC_DRBG в 2013 году (где тоже участвовал NIST и были обнаружены следы влияния АНБ) вопрос доверия к «случайным» параметрам NIST стал ещё острее.

Curve25519, напротив, использует параметры, выбранные по чётким и проверяемым критериям: минимальное простое число нужной формы, стандартная базовая точка, прозрачная процедура выбора коэффициентов. Ничего «случайного», никаких необъяснимых магических чисел.

Рождение Ed25519

В 2011 году Бернштейн в соавторстве с Нильсом Дёйфом, Таней Ланге, Петером Швабе и Бо-Инь Яном опубликовал статью «High-speed high-security signatures», представляющую Ed25519 — конкретный экземпляр схемы подписей EdDSA (Edwards-curve Digital Signature Algorithm) на кривой, математически эквивалентной Curve25519, но записанной в форме скрученной кривой Эдвардса (twisted Edwards curve).

Почему другая форма кривой? Одна и та же эллиптическая кривая может быть записана в разных «координатных системах». Классическая форма Вейерштрасса (Weierstrass), которую использует ECDSA, требует при сложении точек обработки множества особых случаев: точка на бесконечности, удвоение точки, сложение инверсных точек и так далее.

«Стандартные формулы сложения имеют шесть различных случаев… Реализовывать и тестировать это — сущий кошмар».

— Даниэль Бернштейн, «How to design an elliptic-curve signature system», 2014

Форма Эдвардса элегантно обходит эту проблему: формула сложения точек единообразна — одно и то же уравнение работает для всех случаев, включая удвоение и нейтральный элемент. Это не просто математическая красота: единообразные формулы легче реализовать с постоянным временем выполнения, что критически важно для защиты от атак по побочным каналам — утечек информации через время работы, энергопотребление или поведение кэша процессора.

Как работает Ed25519: ключевые отличия

Общая схема Ed25519 похожа на ECDSA, но с несколькими принципиальными архитектурными решениями.

Ключи. Приватный ключ — 32 байта случайных данных. Но используются они не напрямую: сначала приватный ключ хешируется функцией SHA-512, и 64 байта результата делятся на две половины. Первая половина (с определёнными преобразованиями) становится секретным скаляром a, который играет роль «настоящего» приватного ключа. Вторая половина сохраняется как персональное зерно для генерации nonce. Публичный ключ — это точка A = aG, занимающая ровно 32 байта.

Подпись (и вот тут главное отличие). Для подписи сообщения m алгоритм:

1. Вычисляет детерминированный nonce: r = SHA-512(вторая_половина_хеша_ключа || m). Обратите внимание: вместо обращения к генератору случайных чисел nonce вычисляется из приватного ключа и самого сообщения.
2. Получает точку R = rG.
3. Вычисляет скаляр k = SHA-512(R || A || m).
4. Получает S = r + k * a mod L, где L — порядок подгруппы.
5. Подпись — пара (R, S), записанная в фиксированном 64-байтном формате.

Проверка. Зная A, m и (R, S), проверяющий вычисляет k = SHA-512(R || A || m) и проверяет уравнение SG = R + kA на кривой.

Почему детерминированный nonce — это революция

Детерминированная генерация nonce одним ударом устраняет целый класс уязвимостей:

• Нет обращения к генератору случайных чисел при подписи, значит, слабый RNG не приведёт к утечке ключа.
• Повторная подпись одного и того же сообщения одним и тем же ключом даёт одну и ту же подпись — нет риска «случайно» повторить nonce.
• Корректность nonce можно верифицировать детерминированно — упрощается тестирование.

Ни инцидент с Sony PS3, ни проблема Android-кошельков не были бы возможны, если бы использовался алгоритм Ed25519.

Сравнение лицом к лицу

Безопасность: теория и практика

Теоретически оба алгоритма при корректных параметрах дают примерно 128 бит безопасности. Оригинальная страница Ed25519 уточняет: реальная стоимость атаки превышает 2^140 операций.

Но теоретическая стойкость и практическая безопасность — разные вещи. На практике:

Бернштейн формулирует это резче:

«Любая естественная реализация ECDSA активно использует секретные ветвления и секретные индексы массивов».

— Даниэль Бернштейн, «How to design an elliptic-curve signature system», 2014

«Секретные ветвления» (secret branches) — это условные переходы в коде, которые зависят от секретных данных. Они создают измеримую разницу во времени выполнения и открывают дорогу для атак по таймингу.

В 2019 году группа исследователей из Масарикова университета продемонстрировала атаку Minerva: оказалось, что даже утечка битовой длины nonce k при скалярном умножении достаточна для восстановления приватного ключа через решёточную редукцию (lattice reduction). Атакующий наблюдает за временем генерации подписей, собирает несколько сотен (иногда — тысяч) образцов и формулирует задачу как Проблему скрытых чисел (Hidden Number Problem), которая решается алгоритмами LLL/BKZ. Уязвимыми оказались реализации ECDSA в libgcrypt, wolfSSL, Crypto++, SunEC (OpenJDK/Oracle JDK) и даже сертифицированные по FIPS 140-2 смарт-карты — стандарт сертификации попросту не требовал тестирования устойчивости к атакам по побочным каналам.

При этом ни одна из девяти проверенных реализаций EdDSA не оказалась уязвима. Бернштейн прокомментировал это так:

«Команда Minerva заявила о взломе ECDSA в 4, а возможно 5 из 13 криптобиблиотек с поддержкой ECDSA — и в 0 из 9 библиотек с поддержкой EdDSA. Это не случайность: так EdDSA спроектирован».

— Даниэль Бернштейн, «Why EdDSA held up better than ECDSA against Minerva», 2019

Причина устойчивости Ed25519 к Minerva — двойная. Во-первых, EdDSA использует SHA-512 для генерации nonce, давая 512-битный скаляр. Даже если длина утечёт, информации о значении по модулю ~256-битного порядка группы это не даёт. Во-вторых, детерминированный nonce убирает вероятностный источник смещений, который и эксплуатирует атака.

Ed25519 проектировался так, чтобы не было потока данных от секретов к условным переходам и индексам массивов. Как заявлено на официальной странице Ed25519:

«Поэтому данное ПО невосприимчиво к атакам через тайминг кэша, атакам через гиперпоточность и другим атакам по побочным каналам, которые опираются на утечку информации через блок предсказания ветвлений».

— официальная страница Ed25519

Производительность: кто быстрее

Ответ на этот вопрос зависит от реализации. В оригинальной статье 2011 года приводятся цифры для четырёхъядерного Intel Westmere 2.4 ГГц:

• Ed25519: 109 000 подписей/сек, 71 000 проверок/сек;
• подпись занимает 87 548 тактов, проверка (batch) — менее 134 000 тактов.

На практике в разных библиотеках картина различается. Вот бенчмарки на Go (Apple M1):

Источник: Digital Signatures: Mechanics and Go Benchmarks

Ed25519 здесь примерно на 25 % быстрее при подписи и на 20 % — при проверке.

Однако в OpenSSL ситуация обратная: P-256 имеет глубоко оптимизированную ассемблерную реализацию для x86-64, которая опережает реализацию Ed25519 в том же OpenSSL. Это иллюстрирует важный принцип: производительность алгоритма в конкретном продукте определяется не только математикой, но и качеством реализации.

В целом можно сказать: Ed25519 как минимум сопоставим по скорости с ECDSA (P-256) и обычно быстрее в библиотеках, написанных с нуля под эту кривую (libsodium, Go, Rust-реализации). При этом RSA-2048 отстаёт от обоих примерно в 33 раза по скорости подписи.

Простота использования: API и ловушки

Представим типичную задачу разработчика: «подписать JSON и проверить подпись на другом сервисе».

Важное замечание о выборе библиотек. В мире Python существует несколько пакетов с похожими названиями, и их легко перепутать. Чисто-питоновская библиотека python-ecdsa (pip install ecdsa) не предназначена для production-использования — её собственный README прямо об этом предупреждает, а в 2024 году в ней обнаружили уязвимость к атаке Minerva (CVE-2024-23342). Версия 0.19.0 добавила частичное смягчение, но авторы подчёркивают: это не делает библиотеку безопасной от атак по побочным каналам — чисто-питоновский код принципиально не может гарантировать постоянное время выполнения.

Рекомендуемые библиотеки для Python — pyca/cryptography (делегирует криптографию OpenSSL через Rust-биндинги) и PyNaCl (обёртка над libsodium). Обе поддерживаются организацией Python Cryptographic Authority и считаются production-ready.

С Ed25519 на Python (pyca/cryptography) это выглядит так:

from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

# Генерация ключей
private_key = Ed25519PrivateKey.generate()
public_key = private_key.public_key()

# Подпись
signature = private_key.sign(b"my authenticated message")

# Проверка (выбросит InvalidSignature при неудаче)
public_key.verify(signature, b"my authenticated message")

Три строки для генерации и подписи, одна — для проверки. Никаких настроек, выбора кривой, формата или хеш-функции.

С ECDSA код длиннее и требует больше решений:

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes

# Генерация ключей — нужно выбрать кривую
private_key = ec.generate_private_key(ec.SECP256R1())
public_key = private_key.public_key()

# Подпись — нужно выбрать хеш-функцию
signature = private_key.sign(
    b"my authenticated message",
    ec.ECDSA(hashes.SHA256())
)

# Проверка — нужно указать тот же хеш
public_key.verify(
    signature,
    b"my authenticated message",
    ec.ECDSA(hashes.SHA256())
)

Разница может показаться косметической, но каждый дополнительный параметр — это потенциальная ошибка. Какую кривую выбрать? Какой хеш? Как сериализовать подпись — в DER или в «сыром» виде (r || s)? Нужна ли нормализация s (low-S normalization)? Ответы на эти вопросы различаются в разных системах, и несовпадение приводит к трудноуловимым багам совместимости.

Или вот более лаконичный пример с библиотекой PyNaCl (обёртка над libsodium):

from nacl.signing import SigningKey, VerifyKey

# Генерация ключей
signing_key = SigningKey.generate()
verify_key = signing_key.verify_key

# Подпись
signed = signing_key.sign(b"Attack at Dawn")

# Проверка
verify_key.verify(signed)

Минимализм API — не каприз, а осознанный инженерный выбор: чем меньше ручек для настройки, тем меньше способов ошибиться.

То же самое видно и на уровне командной строки. Генерация ключа и подпись файла через OpenSSL (3.0+):

# Генерация ключа Ed25519
openssl genpkey -algorithm Ed25519 -out ed25519_priv.pem

# Извлечение публичного ключа
openssl pkey -in ed25519_priv.pem -pubout -out ed25519_pub.pem

# Подпись файла (флаг -rawin обязателен: Ed25519 хеширует сам)
openssl pkeyutl -sign -inkey ed25519_priv.pem -rawin \
    -in message.txt -out signature.bin

# Проверка подписи
openssl pkeyutl -verify -pubin -inkey ed25519_pub.pem -rawin \
    -in message.txt -sigfile signature.bin

Обратите внимание: привычная команда openssl dgst -sign с Ed25519 не работает — алгоритм сам выполняет хеширование (one-shot signing), поэтому нужен pkeyutl -rawin. Это ещё одно проявление принципа «меньше ручек»: разработчик не может случайно выбрать неподходящий хеш.

А вот как это выглядит на моём любимом языке программирования Nim. Для production-использования рекомендуется модуль Ed25519 из nim-libp2p — чисто-Nim-порт эталонной реализации SUPERCOP ref10 (2 485 строк, без FFI к C), используемый в клиенте Nimbus Ethereum 2.0:

import libp2p/crypto/crypto
import libp2p/crypto/ed25519/ed25519

# Инициализация CSPRNG (использует системную энтропию)
let rng = newRng()

# Генерация ключевой пары Ed25519
var keyPair = EdKeyPair.random(rng[])

# Подпись сообщения
let
  message = "my authenticated message"
  signature = keyPair.seckey.sign(message)

# Проверка подписи
let valid = signature.verify(message, keyPair.pubkey)
echo "Signature valid: ", valid

Для более компактного API можно использовать обёртку над libsodium — nim-libsodium (репозиторий архивирован в 2024 году, но обёртка тонкая и стабильная — вся безопасность обеспечивается самой libsodium):

import libsodium/sodium

assert sodium_init() >= 0
let (publicKey, secretKey) = crypto_sign_keypair()

let
  message = "my authenticated message"
  signature = crypto_sign_detached(secretKey, message)

# Бросает исключение при неудаче
crypto_sign_verify_detached(publicKey, message, signature)

Для ECDSA на кривой secp256k1 (Bitcoin, Ethereum) в Nim есть nim-secp256k1 — биндинги к libsecp256k1, а библиотека Constantine реализует constant-time-арифметику на эллиптических кривых целиком на Nim.

Экосистема: кто где живёт

Где царствует ECDSA

• TLS/HTTPS. Большинство сертификатов в вебе используют ECDSA с кривой P-256. Когда вы видите замочек в адресной строке браузера, скорее всего, за ним стоит именно ECDSA.
• Bitcoin и блокчейны. Bitcoin, Ethereum и десятки других криптовалют подписывают транзакции ECDSA на кривой secp256k1. Вся экосистема — кошельки, ноды, смарт-контракты — построена вокруг этого выбора.
• Корпоративная инфраструктура. PKI, смарт-карты, HSM (аппаратные модули безопасности), государственные стандарты — всё это глубоко завязано на NIST-кривые и ECDSA.

Где доминирует Ed25519

• OpenSSH. Начиная с версии 6.5 (январь 2014), OpenSSH поддерживает Ed25519. Формулировка из release notes была недвусмысленной: «Ed25519 — это схема подписей на эллиптических кривых, которая обеспечивает лучшую безопасность, чем ECDSA и DSA, и хорошую производительность». С версии 9.5 (2023) — это тип ключа по умолчанию при генерации через ssh-keygen. Если вы видите ssh-ed25519 в своём ключе — это оно.
• WireGuard. Современный VPN-протокол, созданный Джейсоном Доненфельдом (Jason Donenfeld), использует Curve25519 для обмена ключами. Философия WireGuard — сознательный отказ от «гибкости шифров»: один набор примитивов, без возможности выбора. Как сказано в вайтпейпере WireGuard: «WireGuard криптографически категоричен. В нём намеренно отсутствует гибкость выбора шифров и протоколов».
• Мессенджеры и современные протоколы. Signal, Matrix, множество новых криптовалют и децентрализованных систем выбирают Ed25519 для подписей.
• Инструменты подписи. OpenBSD signify, minisign, а также GnuPG (с поддержкой Curve25519) — все они используют Ed25519.

Стандартизация: Ed25519 догоняет

Долгое время аргументом против Ed25519 была его «нестандартность» — отсутствие в официальных документах NIST и FIPS. Это изменилось:

• RFC 8032 (январь 2017) — формальная спецификация EdDSA, включая Ed25519 и Ed448.
• RFC 8709 — использование Ed25519 и Ed448 в протоколе SSH.
• FIPS 186-5 (февраль 2023) — NIST официально включил Ed25519 как одобренную схему подписей наряду с RSA и ECDSA. Это убрало последний формальный барьер для использования Ed25519 в системах, требующих соответствия FIPS.

В том же стандарте NIST исключил классический DSA из списка одобренных алгоритмов для генерации новых подписей — косвенное признание того, что индустрия движется вперёд.

Когда ECDSA всё ещё нужен

При всех преимуществах Ed25519, ECDSA никуда не денется в обозримом будущем. Причины прагматические:

• Инерция инфраструктуры. Гигантская PKI-экосистема, миллионы выпущенных сертификатов, аппаратные HSM и смарт-карты — всё это заточено под NIST-кривые и ECDSA. Замена алгоритма в этой среде — это не «переключить флажок», а многолетняя миграция.
• Регуляторные требования. Многие государственные и отраслевые стандарты до сих пор явно ссылаются на конкретные NIST-кривые. Хотя FIPS 186-5 уже включает Ed25519, инерция нормативных документов измеряется годами.
• Блокчейн-совместимость. Если вы работаете с Bitcoin, Ethereum или любым блокчейном на базе secp256k1, Ed25519 просто не впишется без смены всего стека.

Выбор в пользу ECDSA — это не техническая любовь, а компромисс с миром вокруг.

Типичные мифы

«Ed25519 всегда безопаснее ECDSA»

Если оба алгоритма реализованы корректно, используют хорошие параметры и защищены от атак по побочным каналам, оба достаточно надёжны. Преимущество Ed25519 — в том, что корректную реализацию сделать проще, а не в том, что ECDSA «сломан».

«ECDSA устарел, и скоро все от него уйдут»

На практике старые стандарты живут очень долго. Пока существуют браузеры и серверы, заточенные под ECDSA, гигантская PKI-экосистема и железные устройства с аппаратным ускорением ECDSA — полной миграции не будет. Скорее мы увидим гибрид: новые протоколы на Ed25519, старые — на ECDSA.

«Раз оба на эллиптических кривых, разницы нет»

Разница существенная — и на уровне математики (форма кривой, способ генерации nonce, полнота формул сложения), и на уровне инженерии (сколько решений должен принять разработчик, сколько ошибок он может допустить). Это как сравнивать два автомобиля: оба ездят по дорогам, но в одном ABS и ESP идут в базовой комплектации, а в другом нужно самому дозировать торможение.

«Параметры NIST-кривых скомпрометированы АНБ»

Это распространённое опасение, и оно не беспочвенно — но доказательств компрометации P-256 или secp256k1 нет. История, породившая недоверие, связана не с кривыми, а с генератором псевдослучайных чисел Dual_EC_DRBG: в 2007 году исследователи Дэн Шумов и Нильс Фергюсон показали, что две «случайные» точки в его конструкции могут содержать бэкдор, а в 2013 году документы Сноудена подтвердили причастность АНБ. Параметры NIST-кривых (P-256, P-384) были сгенерированы сотрудником АНБ Джерри Солинасом через хеширование SHA-1 от «зерна», происхождение которого так и не объяснено. Доказанной атаки на эти кривые нет, но сам факт непрозрачной генерации в сочетании с доказанным бэкдором в Dual_EC_DRBG подорвал доверие.

Curve25519, напротив, использует минимальный коэффициент (486662), удовлетворяющий требованиям безопасности, — его можно независимо верифицировать, и пространства для скрытых манипуляций просто не остаётся.

Что выбрать для своего проекта

Если обобщить:

Новый протокол, сервис или приложение без жёстких регуляторных ограничений — Ed25519 выглядит разумным выбором по умолчанию:

• минимальный API, сложнее ошибиться;
• детерминированные подписи, нет зависимости от RNG;
• компактные ключи и подписи;
• хорошая производительность;
• одобрен FIPS 186-5 с 2023 года.

Интеграция с существующей инфраструктурой — TLS-сертификаты, PKI, блокчейны, государственные стандарты — чаще потребует ECDSA, потому что окружающий мир уже его использует.

В конечном счёте выбор — не столько про «какой алгоритм математически совершеннее», сколько про баланс между безопасностью реализации, простотой и совместимостью с экосистемой.

Вместо послесловия: что дальше

И ECDSA, и Ed25519 — алгоритмы, основанные на задаче дискретного логарифма на эллиптических кривых. Достаточно мощный квантовый компьютер, реализующий алгоритм Шора, сломает оба. Когда именно это случится — вопрос открытый, но индустрия готовится уже сейчас: NIST в 2024 году финализировал первые постквантовые стандарты (ML-KEM, ML-DSA), а WireGuard добавил поддержку гибридного режима с постквантовым обменом ключами.

Текущий переход от ECDSA к Ed25519 — это не финальная точка, а одна из остановок на пути. Но для ближайших лет Ed25519 остаётся одним из лучших инструментов в арсенале: простым, быстрым и спроектированным так, чтобы сложнее было допустить ошибку, которая стоит миллионы.

Источники

1. Daniel J. Bernstein et al. — «High-speed high-security signatures» — оригинальная статья 2011 года, представляющая Ed25519. Содержит описание алгоритма, обоснование проектных решений и бенчмарки.

2. Ed25519: high-speed high-security signatures — официальная страница проекта Ed25519 с описанием свойств, показателями производительности и ссылками на реализации.

3. Daniel J. Bernstein — «How to design an elliptic-curve signature system» — блог-пост 2014 года с детальной критикой ECDSA и обоснованием преимуществ EdDSA.

4. RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA) — формальная спецификация EdDSA, включая Ed25519 и Ed448 (январь 2017).

5. FIPS 186-5 — Digital Signature Standard (DSS) — стандарт NIST от февраля 2023 года, одобряющий EdDSA наряду с RSA и ECDSA.

6. OpenSSH Release Notes — история изменений OpenSSH, включая переход на Ed25519 как тип ключа по умолчанию в версии 9.5.

7. Jason A. Donenfeld — «WireGuard: Next Generation Kernel Network Tunnel» — вайтпейпер WireGuard (NDSS 2017), описывающий выбор криптографических примитивов и отказ от cipher agility.

8. Soatok — «Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022» — практическое руководство по выбору алгоритма подписи с анализом компромиссов.

9. Comparing SSH Keys: RSA, DSA, ECDSA, or EdDSA? — сравнение типов SSH-ключей с рекомендациями по выбору.

10. Digital Signatures: Mechanics and Go Benchmarks (RSA vs ECDSA vs Ed25519) — бенчмарки цифровых подписей на Go с замерами на Apple Silicon.

11. PyCA cryptography — Ed25519 documentation — документация библиотеки cryptography для Python с примерами кода Ed25519.

12. PyNaCl — Digital Signatures — документация PyNaCl (обёртка libsodium) с примерами подписи и проверки Ed25519.

13. Federal Register — FIPS 186-5 announcement — официальное объявление о вступлении в силу FIPS 186-5.

14. Minerva: The curse of ECDSA nonces — страница проекта Minerva (2019), демонстрирующего атаку на ECDSA через утечку битовой длины nonce.

15. Daniel J. Bernstein — «Why EdDSA held up better than ECDSA against Minerva» — анализ Бернштейна (2019) о том, почему архитектура EdDSA устойчива к классу атак, поразившему ECDSA.