Подпись будет действовать только в паре с этим эфемерным ключем, что не даст его подменить. А публичный эфемерный ключ работает только в паре с приватным, из-за чего "человек посередине" (не зная приватного ключа) не сможет им воспользоваться для создания соединения с клиентом. Подпись служит защитой от подмены ключа
По поводу установки долгоживущего соединения, идея не плохая, но механизм возобновления сессии будет надежнее, при этом особо не влияя на производительность.
Если мы запекаем в бинарнике приложения ephemeral ключ то на сервере нужно будет хранить приватную часть этого ключа не все время а только до выхода новой версии приложения (а если приложение активно развивается то выход минорной версии происходит обычно не реже чем раз в месяц)
Не помню или упоминал в статье, но я хочу сделать чтобы старые клиенты (которые по какой-либо причине не могут получить обновление) могли продолжать работу с обновленными серверами. И если зашивать ключ в бинарник, то без обновления клиента ключ становится статичным, что не безопасно.
попыткой сгладить потенциальный взлом сервера (а иначе как этот долговременный приватный ключ может утечь?) и я такой себе дальше думаю - если уж произошел такой взлом с утечкой приватного ключа то мне кажется что возможность расшифровать перехваченный ранее обмен сообщениями это будет не самая большая проблема в сравнении с потенциальным доступом (в случае взлома) ко всем данным пользователей
Если публичный ключ будет известен клиенту, то приватный можно будет подобрать. Да, шанс подобрать приватный ключ не велик, однако никогда не равен нулю
В начале тоже не понимал в чем вообще смысл этого "Лишнего шага", пока писал свой протокол как раз и разабрался в этом.
Суть в том, что S - результат заранее известной математической операции, по этому оно может иметь предсказуему структуру, иметь какой-то паттерн. Например, каждый второй бит S обязательно 0 (пример взят из воздуха). Из-за чего криптоанализ упрощается и надежность падает. Деревация ключа делает его чуть более непредсказуемым.
А еще S может быть просто слишком длинным или слишком коротким для использования в качестве ключа шифрования, деревация помогает привести его к нужной длине используя весь ключ (а не просто отсечь лишние байты, или заполнить недостающие нулями)
Да, не изобретать велосипед в криптографии, как и в большенстве других отраслей, справедливо для продакшн‑систем. Но пет‑проекты как раз и нужны для того, чтобы экспериментировать. Я не пытался создать промышленный стандарт, этот проект был способом глубже разобраться в теме и поделиться опытом.
Как сказано в начале статьи этот протокол в первую очередь пишется для месенджера, где будет создаваться долгоживущее соединение и все данные будут перегоняться через него.
Идея кодирования API ручки в номере порта довольно интересная и поможет сэкономить байты в UDP пакете, но поскольку в моем сценарии предполагается долгоживущее соединение, использование одного порта для всей сессии будет более выгодным и простым в менеджменте. Однако, этот подход можно добавить в виде опциональной возможности, которая будет выгодна сервисам, создающим единичные, короткие get запросы. Не знаю на сколько целесообразно смешивать два подхода в рамках одного протокола и это внесет сложность в реализацию, по этому на данный момент реализовывать эту возможность я не стану, но обязательно подумаю над этим позже.
Оптимизация раундтипов хорошая возможность для улучшения. Это очень важно для скорости запуска и бесшовных переподключений, но внедрение нулевого раундтипа приведет к сложностям в виде защиты от reply атак, что может быть критично. К тому же я описывал механизм востановления сессии, который не успел реализовать, который должен значительно сократить время повторного подключения. И действительно нужен ли нулевой раундтип в добавку к механизму возобновления сессии нужно будет проверять эксперементально, после его реализации. В первой версии протокола я оставлю текущую схему, но если эксперемент покажет критические зависания связанные с 1-RTT, придется его оптимизировать.
А запекание ephemeral ключа приведет к проблемам с PFS, а в данном случае для меня безопасность приоритетнее скорости
Подпись будет действовать только в паре с этим эфемерным ключем, что не даст его подменить. А публичный эфемерный ключ работает только в паре с приватным, из-за чего "человек посередине" (не зная приватного ключа) не сможет им воспользоваться для создания соединения с клиентом. Подпись служит защитой от подмены ключа
При разрыве соединения будет создано новое и счетчик обнулится, из-за чего багов быть не должно
По поводу установки долгоживущего соединения, идея не плохая, но механизм возобновления сессии будет надежнее, при этом особо не влияя на производительность.
Не помню или упоминал в статье, но я хочу сделать чтобы старые клиенты (которые по какой-либо причине не могут получить обновление) могли продолжать работу с обновленными серверами. И если зашивать ключ в бинарник, то без обновления клиента ключ становится статичным, что не безопасно.
Если публичный ключ будет известен клиенту, то приватный можно будет подобрать. Да, шанс подобрать приватный ключ не велик, однако никогда не равен нулю
В начале тоже не понимал в чем вообще смысл этого "Лишнего шага", пока писал свой протокол как раз и разабрался в этом.
Суть в том, что S - результат заранее известной математической операции, по этому оно может иметь предсказуему структуру, иметь какой-то паттерн. Например, каждый второй бит S обязательно 0 (пример взят из воздуха). Из-за чего криптоанализ упрощается и надежность падает. Деревация ключа делает его чуть более непредсказуемым.
А еще S может быть просто слишком длинным или слишком коротким для использования в качестве ключа шифрования, деревация помогает привести его к нужной длине используя весь ключ (а не просто отсечь лишние байты, или заполнить недостающие нулями)
Да, не изобретать велосипед в криптографии, как и в большенстве других отраслей, справедливо для продакшн‑систем. Но пет‑проекты как раз и нужны для того, чтобы экспериментировать. Я не пытался создать промышленный стандарт, этот проект был способом глубже разобраться в теме и поделиться опытом.
Спасибо за размернутый фидбэк и советы.
Как сказано в начале статьи этот протокол в первую очередь пишется для месенджера, где будет создаваться долгоживущее соединение и все данные будут перегоняться через него.
Идея кодирования API ручки в номере порта довольно интересная и поможет сэкономить байты в UDP пакете, но поскольку в моем сценарии предполагается долгоживущее соединение, использование одного порта для всей сессии будет более выгодным и простым в менеджменте. Однако, этот подход можно добавить в виде опциональной возможности, которая будет выгодна сервисам, создающим единичные, короткие get запросы. Не знаю на сколько целесообразно смешивать два подхода в рамках одного протокола и это внесет сложность в реализацию, по этому на данный момент реализовывать эту возможность я не стану, но обязательно подумаю над этим позже.
Оптимизация раундтипов хорошая возможность для улучшения. Это очень важно для скорости запуска и бесшовных переподключений, но внедрение нулевого раундтипа приведет к сложностям в виде защиты от reply атак, что может быть критично. К тому же я описывал механизм востановления сессии, который не успел реализовать, который должен значительно сократить время повторного подключения. И действительно нужен ли нулевой раундтип в добавку к механизму возобновления сессии нужно будет проверять эксперементально, после его реализации. В первой версии протокола я оставлю текущую схему, но если эксперемент покажет критические зависания связанные с 1-RTT, придется его оптимизировать.
А запекание ephemeral ключа приведет к проблемам с PFS, а в данном случае для меня безопасность приоритетнее скорости