Есть ли разница между ключами 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, который поставляется с BouncyCastle, но я думал, что эти два представляют один и тот же материал о точках на кривой-или я полностью ошибаешься в теории?

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

9
bouncycastle elliptic-curve java security

1 ответов

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

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

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

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

22