JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)

Аннотация

Реализовать криптографические подписи с помощью алгоритма цифровой подписи на кривых Эдвардса (Edwards-Curve Digital Signature Algorithm, EdDSA), описанного в RFC 8032.

Цели

EdDSA — современная схема подписи на эллиптических кривых, у которой есть ряд преимуществ перед схемами подписи, уже имеющимися в JDK. Основная цель этого JEP — реализация этой схемы в том виде, в каком она стандартизирована в RFC 8032. Новая схема подписи не заменяет ECDSA.

Дополнительные цели реализации:

• Разработать платформенно-независимую реализацию EdDSA, которая при том же уровне стойкости работает быстрее существующей реализации ECDSA (использующей нативный код на C). Например, EdDSA на кривой Curve25519 со стойкостью ~126 бит должен работать так же быстро, как ECDSA на кривой secp256r1 со стойкостью ~128 бит.

• Обеспечить независимость времени выполнения от секретных данных при условии, что платформа выполняет сложение и умножение 64-битных целых чисел за постоянное время. Кроме того, в реализации не будет ветвлений, зависящих от секретных данных. Эти свойства важны для защиты от атак по побочным каналам.

Что не является целью

• EdDSA будет реализован только в провайдере SunEC. Реализация этого стандарта в других провайдерах не входит в цели этого JEP.

• API для EdDSA и реализация в SunEC не будут поддерживать произвольные параметры области. При типичном использовании EdDSA применяются только стандартизированные наборы параметров, такие как Ed25519 и Ed448, которые можно указать с помощью идентификаторов, а поддержка произвольных параметров кривой обычно не нужна. API EdDSA должен допускать указание произвольных параметров области за счёт расширения. Такое расширение выходит за рамки этого JEP.

• Интеграция EdDSA с JSSE для TLS 1.3 будет выполнена в последующем улучшении после завершения этого JEP.

Критерии успеха

• Проходят все тестовые векторы из RFC 8032.

• Пропускная способность (измеряемая числом выведенных ключей в секунду в существующем бенчмарке согласования ключей) будет выгодно отличаться от существующей реализации ECC (со сходным уровнем стойкости) на всех платформах.

• Статистический тест покажет, что время выполнения операции подписи не зависит от закрытого ключа.

Мотивация

EdDSA востребован благодаря более высокой безопасности и производительности по сравнению с другими схемами подписи и уже поддерживается во многих других криптографических библиотеках, например в OpenSSL и BoringSSL. Эта схема подписи — необязательный компонент TLS 1.3, но при этом одна из всего трёх схем подписи, разрешённых в TLS 1.3. У некоторых пользователей могут быть сертификаты EdDSA, и они могут отдавать явное предпочтение EdDSA. Эти пользователи оценят возможность использовать EdDSA без сторонней библиотеки. Ещё одно преимущество разработки реализации EdDSA в том, что так нам будет проще разрабатывать и тестировать поддержку этого алгоритма в TLS 1.3.

Описание

Для поддержки EdDSA в провайдер SunEC будут добавлены новые сервисы Signature, KeyFactory и KeyPairGenerator. В API будут добавлены новые классы и интерфейсы для представления ключей EdDSA, а также новые стандартные имена алгоритмов для описания схем подписи EdDSA. API и реализация будут поддерживать все варианты EdDSA (pure, prehashed и context).

Арифметика точек будет использовать операции удвоения и сложения, определённые в RFC 8032, вместе с операцией условного присваивания без ветвлений, чтобы предотвратить атаки по побочным каналам. Арифметика поля будет использовать библиотеку модульной арифметики, разработанную для XDH (JEP 324). При некоторых разумных допущениях о поведении JVM и оборудования объединённая реализация не будет допускать утечки секретных данных через побочные каналы времени выполнения и кэша.

Для описания параметров области кривой и вариантов EdDSA API будет повторно использовать класс NamedParameterSpec, разработанный для XDH. Будут разработаны новые классы и интерфейсы для точек кривой Эдвардса, ключей EdDSA и параметров подписи, включающих контекстную информацию.

Пример использования API:

// example: generate a key pair and sign
KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();
// algorithm is pure Ed25519
Signature sig = Signature.getInstance("Ed25519");
sig.initSign(kp.getPrivate());
sig.update(msg);
byte[] s = sig.sign();

// example: use KeyFactory to contruct a public key
KeyFactory kf = KeyFactory.getInstance("EdDSA");
boolean xOdd = ...
BigInteger y = ...
NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519");
EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y));
PublicKey pubKey = kf.generatePublic(pubSpec);

Альтернативы

• Нативная реализация (как существующий код ECC) может обеспечить более высокую производительность. Производительность EdDSA должна быть сходна с производительностью XDH, поэтому реализация на Java, скорее всего, будет достаточно быстрой.

• Эту схему подписи можно реализовать с помощью арифметики точек из существующего кода ECC, но такой подход не даёт всех преимуществ RFC 8032 в безопасности и производительности.

• Пользователи могли бы применять стороннюю библиотеку с поддержкой EdDSA. Причины включения реализации EdDSA в JDK описаны выше, в разделе «Мотивация».

• Технически, возможно, удалось бы использовать существующие классы API ECC для указания ключей и параметров EdDSA, но это создало бы значительный риск неправильного использования ключей. Подробнее см. JDK-8166597.

Тестирование

Тестирование будет включать тестовые векторы из RFC 8032, дополненные тестами граничных случаев, таких как малые подгруппы и неканонические значения.

Риски и допущения

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