From c27ecd812d3fca2f080e0c1f2ccad3ea14e1e201 Mon Sep 17 00:00:00 2001 From: shr3dd3r Date: Mon, 22 Apr 2024 23:25:33 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=20=D0=BF?= =?UTF-8?q?=D0=BE=D1=82=D0=BE=D0=BA=20=D0=B8=20=D0=BC=D0=B5=D0=BB=D0=BA?= =?UTF-8?q?=D0=B8=D0=B5=20=D0=BF=D1=80=D0=B0=D0=B2=D0=BA=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 8 ++++---- Криптография.md | 2 +- Оглавление.txt | 6 +++--- Поток.md | 7 +++++++ 4 files changed, 15 insertions(+), 8 deletions(-) create mode 100644 Поток.md diff --git a/README.md b/README.md index a26862a..804188a 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,13 @@ -# Неформальная спецификация протокола Stadium версии 0.5 +# Неформальная спецификация протокола Stadium версии 1.0 Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх обширного перечня транспорта и архитектурно не зависящий от оного. Данная спецификация описывает базу, на основе которой могут быть реализованы расширения (_SPX - Stadium Protocol eXtension_) для более конкретных нужд. Основной фокус при работе над этим проектом идёт на: - Минимизация оверхэда и возможность функционирования в условиях низкой пропускной способности канала; -- Приемлимое функционирование в условиях большого количества потерь пакетов; -- Поддержка широкого спектра транспортных протоколов из коробки; -- Гибкое и кастомизируемое сквозное шифрование; +- Приемлимое функционирование в условиях больших потерь пакетов; +- Поддержка широкого спектра транспортных протоколов "из коробки"; +- Гибкое и кастомизируемое шифрование; - Расширяемость и возможность подгонки под конкретные задачи. **Внимание!** В данный момент проект находится в стадии активного проектирования. Данная версия спецификации акцентирует внимание на закреплении общих, преимущественно фундаментальных идей и концепций, потому и является *неформальной*. diff --git a/Криптография.md b/Криптография.md index d835674..67e2ae3 100644 --- a/Криптография.md +++ b/Криптография.md @@ -40,7 +40,7 @@ Более детальное описание схемы: -1. Алиса отправляет Бобу зашифрованный с помощью публичного IK запрос рукопожатия, содержащий публичный SSK Алисы; инициализационное значение и константу для KDF, отвечающей за обновление PEK Алисы; инициализационное значение и константу для KDF, генерирующего StreamId Алисы; а также прочие параметры создаваемых сессии и потока. +1. Алиса отправляет Бобу зашифрованный с помощью публичного IK запрос рукопожатия с целью создания новой сессии и шифрованного потока, содержащий публичный SSK Алисы; инициализационное значение и константу для KDF, отвечающей за обновление PEK Алисы; инициализационное значение и константу для KDF, генерирующего StreamId Алисы; а также прочие параметры создаваемых сессии и потока. 2. Боб принимает шифрованный запрос рукопожатия, расшифровывает с помощью своего приватного IK и отвечает Алисе своим публичным SSK; инициализационным значением и константой KDF, отвечающей за обновление PEK Боба; инициализационное значение и константу для KDF, генерирующего StreamId Боба; а также прочей своей частью параметров, зашифровав их с помощью публичного SSK Алисы. 3. Алиса шифрует пакет с помощью своего PEK, подписывает с помощью своего приватного SSK, снабжает текущим StreamId и отправляет Бобу. 4. Боб получает пакет, проверяет его с помощью публичного SSK Алисы и расшифровывает с помощью PEK Алисы. После этого Алиса и Боб обновляют PEK и StreamId Алисы с помощью двух KDF. diff --git a/Оглавление.txt b/Оглавление.txt index 5f94441..0ba3d95 100644 --- a/Оглавление.txt +++ b/Оглавление.txt @@ -21,7 +21,7 @@ 4.3. Ответ на рукопожатие 5. Сессия 5.1. Поток - 5.1.1. Состояние + 5.1.1. Состояние [StreamState; Running, Desynchronized] 5.1.2. Идентификатор потока [StreamId, SrvStreamId, CltStreamId] 5.1.3. Секрет потока [StreamSecret] 5.1.4. Криптографические параметры потока @@ -39,7 +39,7 @@ 7.1. Заголовок пакета 7.1.1. Код аутентификации [Packet Authentication Code, PAC, CltPAC, SrvPAC; проверка целостности и достоверности] 7.1.2. Флаги - 7.1.3. Идентификатор ответа [RespId] + 7.1.3. Идентификатор ответа [RespId; мб стоит сделать PacketID и обязательным для всех, дабы перезапрашивать в случае повреждения] 7.2. Полезная нагрузка 7.2.1. Шум в полезной нагрузке пакета 7.3. Структура и шифрование @@ -52,7 +52,7 @@ 8.2.3. Гарантия обнаружения недоставки [?] 8.2.4. Гарантия целостности 8.2.5. Наличие шифрования - 8.3. Список адаптеров [возможно, что стоит вынести в отдельную спеку] + 8.3. Список адаптеров [мб стоит вынести в отдельную спеку] 8.3.1. UDP-raw 8.3.2. TCP-raw 8.3.3. HTTP1.1-text+binary [текстовые HTTP/1.1 POST-запросы и бинарные ответы] diff --git a/Поток.md b/Поток.md new file mode 100644 index 0000000..1ae0e01 --- /dev/null +++ b/Поток.md @@ -0,0 +1,7 @@ +# Поток + +Поток - это логический канал для передачи пакетов, существующий в пределах конкретной сессии. Потоки могут создаваться и уничтожаться по инициативе клиента, сервер может только ограничивать создание новых потоков или уничтожать потоки исходя из соображений защиты от DoS-атак. При создании новой сессии всегда создаётся как минимум один поток. + +У потока есть некий набор параметров, часть из которых он разделяет с сессией. У каждого потока есть свой уникальный идентификатор. Поток может быть как "шифрованным", так и "нешифрованным", что влияет на формат пакетов: в нешифрованном потоке, идентификатор потока статичен, а в шифрованном - обновляется и уникален для каждого пакета. Шифрованный поток может находиться в одном из двух состояний: "работает" или "рассинхронизирован", а нешифрованный только в первом. Поток может гарантировать последовательность отправки пакетов и информирование в случае недоставки или повреждения пакета, но это остаётся на усмотрение клиента и отключаемо в случае ненадобности. + +Поток привязан к транспортному протоколу, по которому осуществляется физическая передача пакетов и существует в рамках жизни сессии. Один транспортный протокол может использоваться сразу несколькими потоками. Все потоки двунаправленны, т.е. пакеты могут отправляться как от клиента к серверу, так и наоборот.