Что такое библиотека C++ с ECDiffieHellmanCng-совместимой реализацией?
Я ищу решение для обмена ключами между приложением.NET и встроенным устройством. Две конечные точки имеют общий секретный ключ, что делает алгоритм Eiffiptic Curve Diffie-Hellman (ECDH) превосходным для безопасного обмена главным секретом для сеанса.
Есть хорошая библиотека C++, crypto ++, которая реализует ECDH и подходит для встроенного устройства. Однако его реализация ECDH отличается от реализации Mirosoft ECDiffieHellmanCng (как упоминалось в часто задаваемых вопросах). Мы хотели бы оставаться совместимыми с алгоритмами безопасности.NET, чтобы мы могли придерживаться управляемого кода для приложения для ПК (сейчас, или если мы будем использовать CNG, когда мы когда-нибудь выпустим XP).
Кто-нибудь видел реализацию, кроме Microsoft, которая совместима с Microsoft? В качестве альтернативы, существуют ли другие хорошие решения для обмена ключами между кодом.NET и встроенным кодом C++ для использования с предварительно общими ключами?
Обновление 2010-01-27: чтобы уточнить, я пытаюсь использовать ECDH для выполнения двухсторонней аутентификации и обмена ключами между двумя конечными точками ad-hock, которые не доверяют друг другу, пока не увидят, что они разделяют один и тот же секрет. Это похоже на сценарий сопряжения Bluetooth, когда общий секретный ключ передается вне полосы (за исключением того, что в моем случае устройства могут не находиться рядом друг с другом).
3 ответа
Ничто из приведенного вами часто задаваемого вопроса так или иначе не ссылается на реализацию СПГ. Я думаю, что утверждения в FAQ в целом верны, особенно ситуация с патентами. Тем не менее, существуют некоторые стандарты, и в частности, NIST США опубликовал некоторые стандарты. См., Например, Рекомендацию для схем установления парных ключей с использованием криптографии с дискретным логарифмом.
Для совместимости вам лучше использовать RSA. Вы не найдете много бесплатных реализаций ECC из-за патентного минного поля.
Как насчет того, чтобы одна сторона генерировала случайный ключ, зашифровывала его открытым ключом другой стороны и подписывала своим собственным закрытым ключом. Затем другая сторона может проверить подпись и расшифровать общий ключ.
Если вы беспокоитесь о атаках воспроизведения (обратите внимание, что схема ECDH, которую вы планировали использовать, не защищала от них - если только вы не планировали использовать эфемерные ключи), вы можете заставить обе стороны сгенерировать случайный ключ, зашифровав его с помощью другой стороны. открытый ключ, а затем объединить два ключа в некотором роде.
Еще лучше, вероятно, использовать некоторый стандартный протокол: рассмотрим TLS с проверкой сертификата клиента. Вы можете жестко закодировать клиентские и серверные сертификаты.