Есть ещё key-transport protocol. Например, так называемый «цифровой конверт». Вот в нём секретный ключ действительно передаётся. Отличается от Diffie-Hellman.
В профессиональной литературе протокол Diffie-Hellman в различных его реинкарнациях называется key-agreement protocol. По-русски это будет «протокол согласования ключа». И это действительно так. Ничего там не передаётся, кроме сеансовых общедоступных ключей, заверенных ЭЦП, а совместными действиями вырабатывается (согласовывается) одноразовый сеансовый секретный ключ.
Вот зачем тут фантазировать. Так можно далеко зайти. Резюмирую. К продукту много различных вопросов. Некоторые подходы подозрительны. Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
Могу предположить, что хотели избавить пользователей от необходимости получать новые ключи.
Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо? И вообще, что значит «получать новые ключи»? Если речь идёт о сертификате общедоступного ключа, то тут единый подход, который в общем случае не зависит от алгоритма ЭЦП. Всё регулируется положениями сертификационной политики/практики. Могут быть отдельные исключения, например в случае lightweight cryptography (LC). Но в основном это касается жизненного цикла сертификата. Обычно в случае LC он короче. Так что не понятно, что Вы имеете в виду.
Кстати, если мне в каком-либо продукте безальтернативно навязываю RSA, то это точно не в пользу этого продукта. Специалист понимает, к чему это в итоге может привести (см. вышеизложенные аргументы и рассуждения).
А в чём проблема? Это как раз к вопросу о преимуществе ЕСС. Просто замените RSA в режиме ЭЦП на любой другой алгоритм ЭЦП на основе точек эллиптической кривой. Это может быть что угодно: ECDSA, наш российский национальный стандарт и пр. На любую ЭЦП из ECC. Всегда получите выигрыш. В этом же смысл. Мы же ведь на RSA не молимся? Так что надо просто уметь правильно пользоваться этими вещами.
Я выше уже написал, почему RSA проигрывает любому алгоритму ECC. Если хотите точнее, то есть теоретические результаты, которые показывают, что проблема факторизации (FP), которая лежит в основе криптостойкости RSA, связана с DLP. Из этого факта в частности следует, что для FP существуют алгоритмы факторизации субэкспоненциальной трудоёмкости. Соответственно при заданном уровне криптостойкости, для компенсации уязвимости по причине существования алгоритмов такой трудоёмкости, приходится «раздувать» разрядность RSA-ключей, как секретных, так и общедоступных. Со всеми вытекающими последствиями.
Если имеется два различных варианта, то для них так или иначе должен быть программный код и для клиента и для сервера. Вот и вопрос: А зачем это дублирование? Тем более, что оба варианта обеспечивают одну и ту же функциональность. Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
Если RSA используется в режиме ЭЦП, то тогда проигрыш по разрядности общедоступного ключа при фиксированном уровне криптостойкости будет по сравнению с ECDSA, например, или по сравнению с любым другим алгоритмом ЭЦП на основе арифметики точек эллиптической кривой. Вообще, RSA в настоящий момент не соответствует трендам современной криптографии. Проблема не только с издержками при хранении сертификатов общедоступных ключей, но и с вычислительными трудозатратами на формирование/проверку ЭЦП и зашифрование/расшифрование. Хотя этот аспект также связан с разрядностью ключей.
…каким образом отказ от DHE позволит экономить долговременную память.</span>
Очень просто. Если использовать, например, ECDH при некотором заданном уровне криптостойкости, то разрядность (длина в битах) общедоступного ключа для ECDH будет на порядок короче, чем разрядность общедоступного ключа для DH при том же уровне криптостойкости. Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит? Что касается выпуска и обслуживание сертификатов, то за это надо платить. Обычно, если разрядность общедоступного ключа превышает некоторый лимит, то подключается дорогой тариф. Дальше всё регулирует рынок. Если за тот же самый уровень криптостойкости мне необходимо платить больше, то я просто откажусь от такого продукта. Если разрядность не превышает лимита, то возникает вопрос о криптостойкости. Если он низкий, то я опять же откажусь от продукта, но уже по другой причине. Это простые соображения. Обычно их все понимают.
…т.к. его авторам не нужно ничего реализовывать самим - они используют стороннюю библиотеку для этого.
А в сторонней библиотеке не должно быть реализации всей байды, которая характерна для ECC, и всего стального для реализации примитивов на основе арифметики элементов конечного поля? Программный код для всего этого откуда возьмётся? Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
Вот от это поясните, пожалуйста. В контексте LIghtway о каких долговременных ключах идет речь и каким образом отказ от DHE позволит экономить долговременную память.
Ну, давайте с самого начала. Что Вы понимаете под lightway? Может это lightweight? В смысле «облегчённая криптография» (lightweight cryptography)? Если так, то почему эта тема вдруг нарисовалась? Следующий вопрос. Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей? Надо всё выяснять по-порядку. А то Вы начинаете перескакивать с одной темы на другую.
Выбор ЕСС для реализации криптографических примитивов – не дань моде. За этим стоят вполне рациональные соображения. Прочитать популярное объяснение про ECDLP и DLP можно здесь habr.com/ru/post/564596 в подкате. Если говорить о практических последствиях использования ECC, то это выражается в существенной экономии долговременной памяти, предназначенной для хранения общедоступных ключей. В первую очередь это касается PKI (Вы понимаете, что это всё про бабки, попросту говоря?). Выигрыш достигает порядка и более в зависимости от требований криптостойкости. Так что ECC – это даже не стандарт де-юро, но стандарт де-факто. Странно предполагать, что разработчики при реализации криптопримитивов вдруг начнут отказывать от лучшего в пользу худшего. Так что ваши аргументы выглядят несерьёзно. В духе: А вдруг кто-то что-то не так сделает? Вот уж мы подстрахуемся. Что касается компактности кода, то это тоже не так. Арифметика точек в подгруппе простого порядка группы точек эллиптической кривой принципиально отличается от арифметики элементов подгруппы простого порядка мультипликативной группы конечного поля. Имеют совершенно различную реализация. Значит, если у нас есть и то, и другое, то это неизбежно приведёт к разрастанию кода. Это объективно. Без всяких малозначащих слов «один дополнительный cipher suite в конце списка и всё.»
WolfSSL использует библиотеку wolfCrypt, которая включает ECC в ряду прочего. Поэтому приведённый пример некорректен. А можете привести пример чего-то такого криптографического и достаточно распространённого, что не включает реализацию примитивов ECC? Просто даже интересно…
2. Каждый приглашённый генерирует свою пару ключей, и сообщает организатору публичную часть.
Приглашённый должен получить сертификат на свой общедоступный ключ. В нём будет точно указано, кому он принадлежит. Иначе, кто угодно может выдать себя за приглашённого. Если организатор отправляет приглашённому его же общедоступный ключ, заверенный ЭЦП организатора, то информация о приглашённом раскрывается. Это всего лишь одно наблюдение. В предложенном протоколе есть и другие «дыры». Вообще, обсуждать разные криптоподелки особого смысла нет. Если делаешь что-то новое, то доказывай. Если информация не разглашается, то необходимо доказать либо ZKP-свойство, либо, как альтернатива, свойства WI и WH.
А Вы уверены, что всё понимаете?
Есть ещё key-transport protocol. Например, так называемый «цифровой конверт». Вот в нём секретный ключ действительно передаётся. Отличается от Diffie-Hellman.
Я всегда подозреваю. Только в одном случае мне не дают прямого повода, в другом – этих поводов вагон и маленькая тележка. Вот и весь сказ.
В профессиональной литературе протокол Diffie-Hellman в различных его реинкарнациях называется key-agreement protocol. По-русски это будет «протокол согласования ключа». И это действительно так. Ничего там не передаётся, кроме сеансовых общедоступных ключей, заверенных ЭЦП, а совместными действиями вырабатывается (согласовывается) одноразовый сеансовый секретный ключ.
Вот зачем тут фантазировать. Так можно далеко зайти. Резюмирую. К продукту много различных вопросов. Некоторые подходы подозрительны. Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
Мне эта логика не понятна. Зачем делать криво и некрасиво, когда можно сделать ровно и красиво? Всю подноготную я уже изложил.
Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо? И вообще, что значит «получать новые ключи»? Если речь идёт о сертификате общедоступного ключа, то тут единый подход, который в общем случае не зависит от алгоритма ЭЦП. Всё регулируется положениями сертификационной политики/практики. Могут быть отдельные исключения, например в случае lightweight cryptography (LC). Но в основном это касается жизненного цикла сертификата. Обычно в случае LC он короче. Так что не понятно, что Вы имеете в виду.
Кстати, если мне в каком-либо продукте безальтернативно навязываю RSA, то это точно не в пользу этого продукта. Специалист понимает, к чему это в итоге может привести (см. вышеизложенные аргументы и рассуждения).
А в чём проблема? Это как раз к вопросу о преимуществе ЕСС. Просто замените RSA в режиме ЭЦП на любой другой алгоритм ЭЦП на основе точек эллиптической кривой. Это может быть что угодно: ECDSA, наш российский национальный стандарт и пр. На любую ЭЦП из ECC. Всегда получите выигрыш. В этом же смысл. Мы же ведь на RSA не молимся? Так что надо просто уметь правильно пользоваться этими вещами.
В нём совершенно ясно указано, как различаются ключи для ECDH и DH для уровня криптостойкости 80 бит, например.
Я выше уже написал, почему RSA проигрывает любому алгоритму ECC. Если хотите точнее, то есть теоретические результаты, которые показывают, что проблема факторизации (FP), которая лежит в основе криптостойкости RSA, связана с DLP. Из этого факта в частности следует, что для FP существуют алгоритмы факторизации субэкспоненциальной трудоёмкости. Соответственно при заданном уровне криптостойкости, для компенсации уязвимости по причине существования алгоритмов такой трудоёмкости, приходится «раздувать» разрядность RSA-ключей, как секретных, так и общедоступных. Со всеми вытекающими последствиями.
А какая разница, какой библиотекой пользоваться?
Если имеется два различных варианта, то для них так или иначе должен быть программный код и для клиента и для сервера. Вот и вопрос: А зачем это дублирование? Тем более, что оба варианта обеспечивают одну и ту же функциональность. Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
Очень просто. Если использовать, например, ECDH при некотором заданном уровне криптостойкости, то разрядность (длина в битах) общедоступного ключа для ECDH будет на порядок короче, чем разрядность общедоступного ключа для DH при том же уровне криптостойкости. Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит? Что касается выпуска и обслуживание сертификатов, то за это надо платить. Обычно, если разрядность общедоступного ключа превышает некоторый лимит, то подключается дорогой тариф. Дальше всё регулирует рынок. Если за тот же самый уровень криптостойкости мне необходимо платить больше, то я просто откажусь от такого продукта. Если разрядность не превышает лимита, то возникает вопрос о криптостойкости. Если он низкий, то я опять же откажусь от продукта, но уже по другой причине. Это простые соображения. Обычно их все понимают.
А в сторонней библиотеке не должно быть реализации всей байды, которая характерна для ECC, и всего стального для реализации примитивов на основе арифметики элементов конечного поля? Программный код для всего этого откуда возьмётся? Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
Ну, давайте с самого начала. Что Вы понимаете под lightway? Может это lightweight? В смысле «облегчённая криптография» (lightweight cryptography)? Если так, то почему эта тема вдруг нарисовалась? Следующий вопрос. Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей? Надо всё выяснять по-порядку. А то Вы начинаете перескакивать с одной темы на другую.
2. Каждый приглашённый генерирует свою пару ключей, и сообщает организатору публичную часть.
Приглашённый должен получить сертификат на свой общедоступный ключ. В нём будет точно указано, кому он принадлежит. Иначе, кто угодно может выдать себя за приглашённого. Если организатор отправляет приглашённому его же общедоступный ключ, заверенный ЭЦП организатора, то информация о приглашённом раскрывается. Это всего лишь одно наблюдение. В предложенном протоколе есть и другие «дыры». Вообще, обсуждать разные криптоподелки особого смысла нет. Если делаешь что-то новое, то доказывай. Если информация не разглашается, то необходимо доказать либо ZKP-свойство, либо, как альтернатива, свойства WI и WH.