Comments 38
честно говоря, я не понял где тут киллер-фича.
динамические внутренние адреса клиентов? в openvpn оно есть, в wg, думаю, не так сложно прикрутить.
производительность? что-то у меня есть сомнения в превосходстве над ipsec и wg. плюс для ipsec полно аппаратных решений.
2k LoC? ну это жирный плюс, конечно, но на киллер-фичу, думаю, не тянет.
динамические внутренние адреса клиентов?
да, в сравнении с wg в качестве основного преимущества рассматривается именно это. ну и как дополнительные — возможность работы через tcp и потенциальная возможность писать плагины для маскировки трафика.
https://lightway.com/docs/lightway-core/1.0.0/faq.html
Если по какой-то причине использовать ECDH невозможно, система обращается к классическому протоколу Диффи — Хеллмана (DH).
Вот интересно, а что это за причины такие могут быть? Тем более, как я понял, борьба шла за компактность кода. Боролись, боролись, а потом вдруг, бац, и изменили принципам. Подозрительно как-то…
Если вдруг DPI перегружен, и не хочет тратить такты на ECDH, то махнёт клиентам, что ECDH не получается, и они переключатся на DH. Удобная фитча ;)
Приблизительно так и подумал. Только DPI тут скорее всего ни при чём. Если заранее в DH предусмотрен низкий уровень криптостойкости по сравнению с ECDH, то переключение с более криптостойкого на менее криптостойкий протокол происходит просто по звонку товарища майора. Я бы не стал пользоваться таким VPN-сервисом и другим не посоветовал. Замечу, что когда речь идёт о вопросах безопасности, параноидальный подход вполне оправдан.
Кстати, это может быть связано с экспортными ограничениями на криптографию. Например, вариант с DH, который гарантирует 40-битный уровень криптостойкости, подключается в том случае, когда софт экспортируется в страны, на которые не распространяется юрисдикция страны-регулятора. Обычно этим такими штуками занимаются США.
Ну например, если wolfSSL на одной из сторон собран без поддержки ECC. Redhat вон сколько лет не хотели ECC добавлять в свои дистры из-за патентных ограничений.
WolfSSL использует библиотеку wolfCrypt, которая включает ECC в ряду прочего. Поэтому приведённый пример некорректен.
При чем тут что она использует? Поддержку ECC в wolfSSL можно отключить при сборке.
А можете привести пример чего-то такого криптографического и достаточно распространённого
Пример я уже привел: долгое время в RHEL/CentOS была отключена поддержка ECC, включили ее только в CentOS 6.5 или 7, не помню точно. Кто-то может руководствоваться анологичными соображениями. Или, возможно, кто-то захочет создать собственную реализацию протокола, но не может или не хочет по каким-то причинам использовать ECC. Если вас беспокоит компактность кода, то на нее это влияния практически не окажет - просто при конфигурации контекста передаете один дополнительный cipher suite в конце списка и все.
Так что ECC – это даже не стандарт де-юро, но стандарт де-факто.
Может быть, в этом и проблема?
Странно предполагать, что разработчики при реализации криптопримитивов вдруг начнут отказывать от лучшего в пользу худшего. Так что ваши аргументы выглядят несерьёзно.
Почему странно? В TLS 1.3 точно так же есть поддержка и ECDHE и DHE.
В первую очередь это касается PKI (Вы понимаете, что это всё про бабки, попросту говоря?).
Вот это поясните, пожалуйста. В контексте LIghtway о каких долговременных ключах идет речь и каким образом отказ от DHE позволит экономить долговременную память.
Что касается компактности кода, то это тоже не так. Арифметика точек в подгруппе простого порядка группы точек эллиптической кривой принципиально отличается от арифметики элементов подгруппы простого порядка мультипликативной группы конечного поля. Имеют совершенно различную реализация. Значит, если у нас есть и то, и другое, то это неизбежно приведёт к разрастанию кода. Это объективно.
Мы сейчас о каком коде говорим? К разрастанию кода Lightway это не приведет, т.к. его авторам не нужно ничего реализовывать самим - они используют стороннюю библиотеку для этого. Все влияние на размер кодовой базы Lightway сводится к тому, что вместо
wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-CHACHA20-POLY1305");они пишут
wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305"); Напомню, что компактность кода речь пошла вот из-за этого вашего поста:
Тем более, как я понял, борьба шла за компактность кода. Боролись, боролись, а потом вдруг, бац, и изменили принципам. Подозрительно как-то…
Вот от это поясните, пожалуйста. В контексте LIghtway о каких долговременных ключах идет речь и каким образом отказ от DHE позволит экономить долговременную память.
Ну, давайте с самого начала. Что Вы понимаете под lightway? Может это lightweight? В смысле «облегчённая криптография» (lightweight cryptography)? Если так, то почему эта тема вдруг нарисовалась? Следующий вопрос. Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей? Надо всё выяснять по-порядку. А то Вы начинаете перескакивать с одной темы на другую.
Что Вы понимаете под lightway?
Lightway - это название протокола, который мы сейчас обсуждаем)
Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей?
Нет, не полагаю. Но при условии, что они используют RSA, то отказ от DHE в пользу ECDHE никак не повлияет PKI.
…т.к. его авторам не нужно ничего реализовывать самим - они используют стороннюю библиотеку для этого.
А в сторонней библиотеке не должно быть реализации всей байды, которая характерна для ECC, и всего стального для реализации примитивов на основе арифметики элементов конечного поля? Программный код для всего этого откуда возьмётся? Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
Необязательно. Можно использовать не wolfSSL, а системный OpenSSL, например.
А какая разница, какой библиотекой пользоваться?
Если имеется два различных варианта, то для них так или иначе должен быть программный код и для клиента и для сервера. Вот и вопрос: А зачем это дублирование? Тем более, что оба варианта обеспечивают одну и ту же функциональность. Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
Это почему? При правильном использовании DHE обеспечивает адекватную безопасность.
В нём совершенно ясно указано, как различаются ключи для ECDH и DH для уровня криптостойкости 80 бит, например.
…каким образом отказ от DHE позволит экономить долговременную память.</span>
Очень просто. Если использовать, например, ECDH при некотором заданном уровне криптостойкости, то разрядность (длина в битах) общедоступного ключа для ECDH будет на порядок короче, чем разрядность общедоступного ключа для DH при том же уровне криптостойкости. Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит? Что касается выпуска и обслуживание сертификатов, то за это надо платить. Обычно, если разрядность общедоступного ключа превышает некоторый лимит, то подключается дорогой тариф. Дальше всё регулирует рынок. Если за тот же самый уровень криптостойкости мне необходимо платить больше, то я просто откажусь от такого продукта. Если разрядность не превышает лимита, то возникает вопрос о криптостойкости. Если он низкий, то я опять же откажусь от продукта, но уже по другой причине. Это простые соображения. Обычно их все понимают.
Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит?
Сбавьте тон, пожалуйста. Подобные наезды - это не слишком-то профессионально. Я прекрасно понимаю, о чем говорю.
У нас есть конкретный протокол, который использует (EC)DHE для обмена ключами и RSA для подписи в обоих случаях.
Я выше уже написал, почему RSA проигрывает любому алгоритму ECC. Если хотите точнее, то есть теоретические результаты, которые показывают, что проблема факторизации (FP), которая лежит в основе криптостойкости RSA, связана с DLP. Из этого факта в частности следует, что для FP существуют алгоритмы факторизации субэкспоненциальной трудоёмкости. Соответственно при заданном уровне криптостойкости, для компенсации уязвимости по причине существования алгоритмов такой трудоёмкости, приходится «раздувать» разрядность RSA-ключей, как секретных, так и общедоступных. Со всеми вытекающими последствиями.
Но если вы выкинете DHE из Lightway, то от RSA и необходимости хранить ключи все равно не избавитесь.
А в чём проблема? Это как раз к вопросу о преимуществе ЕСС. Просто замените RSA в режиме ЭЦП на любой другой алгоритм ЭЦП на основе точек эллиптической кривой. Это может быть что угодно: ECDSA, наш российский национальный стандарт и пр. На любую ЭЦП из ECC. Всегда получите выигрыш. В этом же смысл. Мы же ведь на RSA не молимся? Так что надо просто уметь правильно пользоваться этими вещами.
Это уже не ко мне вопрос. Я тоже не могу понять, почему разработчики предусмотрели возможность использовать DHE вместо ECDHE, но не предусмотрели возможности использовать, например, ECDSA. Но вот почему-то решили использовать только RSA. Могу предположить, что хотели избавить пользователей от необходимости получать новые ключи. Либо проблема в их инфраструктуре. Это все же изначально коммерческий продукт, который разрабатывался под их внутренние требования, а уже потом ушел в open source. Поэтому и подход к разработке немного другой.
Могу предположить, что хотели избавить пользователей от необходимости получать новые ключи.
Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо? И вообще, что значит «получать новые ключи»? Если речь идёт о сертификате общедоступного ключа, то тут единый подход, который в общем случае не зависит от алгоритма ЭЦП. Всё регулируется положениями сертификационной политики/практики. Могут быть отдельные исключения, например в случае lightweight cryptography (LC). Но в основном это касается жизненного цикла сертификата. Обычно в случае LC он короче. Так что не понятно, что Вы имеете в виду.
Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо?
Это всего лишь предположение. Скорее всего до создания этого протокола, они использовали какое-то другое решение. Возможно, OpenVPN или ikev2, поэтому у существующих пользователей на руках уже есть: сертификат CA, сертификат самого пользователя и соответствующий приватный ключ (RSA). Поэтому для перехода на новый протокол, ему нужно только скачать новый клиент. И самому провайдеру не нужно обновлять PKI.
Вот зачем тут фантазировать. Так можно далеко зайти. Резюмирую. К продукту много различных вопросов. Некоторые подходы подозрительны. Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
Это просто наиболее правдоподобное объяснение, которое я могу придумать. К протоколу есть вопросы, тут согласен. Но если вы подозреваете, что VPN-провайдер активно сотрудничает со спецслужбами, то тут даже идеально спроектированный протокол не поможет.
Кстати, если мне в каком-либо продукте безальтернативно навязываю RSA, то это точно не в пользу этого продукта. Специалист понимает, к чему это в итоге может привести (см. вышеизложенные аргументы и рассуждения).
В профессиональной литературе протокол Diffie-Hellman в различных его реинкарнациях называется key-agreement protocol. По-русски это будет «протокол согласования ключа». И это действительно так. Ничего там не передаётся, кроме сеансовых общедоступных ключей, заверенных ЭЦП, а совместными действиями вырабатывается (согласовывается) одноразовый сеансовый секретный ключ.
Новый открытый VPN-протокол — на что обратить внимание