Есть ли разница между ключами ECDH и ECDSA?

Я создаю сетевое приложение, которое использует BouncyCastle в качестве поставщика криптографии. Допустим, у вас есть это для создания пары ключей:

ECParameterSpec ecSpec = ECNamedCurveTable.getParameterSpec("prime192v1");
KeyPairGenerator g = KeyPairGenerator.getInstance("ECDSA", "BC");
g.initialize(ecSpec, new SecureRandom());
KeyPair pair = g.generateKeyPair();

Я не понимаю, почему вы получаете экземпляр ECDSA KeyPairGenerator. Почему не написано просто EC? Я знаю, что есть тип ECDH Key, который поставляется с BouncyCastle, но я подумал, что они представляют собой одно и то же, что касается точек на кривой - или я полностью ошибаюсь в теории, лежащей в основе этого?

Причина, по которой я спрашиваю, заключается в том, что прямо сейчас мое приложение использует ECDH для установки секретного ключа AES, но теперь я хочу использовать тот же ключ EC для подписи каждого сообщения с помощью ECDSA.


java security bouncycastle elliptic-curve
person Hut8    schedule 11.02.2011    source источник

Ответы (1)


arrow_upward
31
arrow_downward

ECDSA и ECDH взяты из разных стандартов (ANSI X9.62 и X9.63 соответственно) и используются в разных контекстах. X9.63 явно повторно использует элементы из X9.62, включая стандартное представление открытых ключей (например, в сертификатах X.509). Следовательно, пары ключей ECDSA и ECDH в значительной степени взаимозаменяемы. Однако вопрос о том, разрешит ли данная реализация такой обмен, остается открытым. Исторически сложилось так, что (EC) DSA и (EC) DH происходят из разных миров.

Однако обратите внимание, что контексты использования весьма различны. Криптография - это нечто большее, чем вычисления на эллиптических кривых; необходимо учитывать «жизненный цикл ключа». Проще говоря, вы не хотите управлять ключами согласования ключей и ключами подписи с помощью одних и тех же процедур. Например, если вы потеряете свой ключ соглашения (ваша собака ест вашу смарт-карту - не смейтесь, это действительно происходит), тогда вы больше не сможете расшифровать данные, которые были зашифрованы относительно этого ключа (например, зашифрованные электронные письма, отправленные вам, и хранится в зашифрованном виде). С точки зрения бизнеса потеря ключа также может означать потерю сотрудника (сотрудника уволили, сбил автобус, или он вышел на пенсию, или что-то еще). Следовательно, ключи шифрования (включая ключи согласования ключей) должны часто передаваться на хранение (например, копия закрытого ключа печатается и хранится в сейфе). С другой стороны, потеря ключа подписи не означает потери данных; ранее выданные подписи еще можно проверить; восстановление после такой потери так же просто, как создание новой пары ключей. Однако наличие системы условного депонирования имеет тенденцию автоматически лишать подписи любой юридической ценности, которая может быть к ним прикреплена.

Кроме того, в более общем плане я бы настоятельно не советовал использовать один и тот же закрытый ключ в двух разных алгоритмах: взаимодействие между алгоритмами не изучено полностью (простое изучение одного алгоритма - уже тяжелая работа). Например, что произойдет, если кто-то начнет кормить ваш протокол на основе ECDH точками кривой, извлеченными из подписей ECDSA, которые вы вычислили с тем же закрытым ключом?

Поэтому вам действительно не следует повторно использовать один и тот же ключ для ECDH и ECDSA.

person Thomas Pornin    schedule 11.02.2011
comment
Большое спасибо за это объяснение - я должен более внимательно прочитать свои стандарты :-) - person Hut8; 12.02.2011