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