Множественные правки и добавления

Добавлено упоминание генерации шума на уровне транспортного адаптера; уточнения касательно разбиения пакетов; у шума можно настроить его характер, т.е. статистические характеристики не касающиеся его количества; формат LBM теперь формат KLV; у транспортных адаптеров теперь есть кодовое имя, определён базовый интерфейс и добавлено перечисление обязательных и рекомендуемых к имплементации видов адаптеров.

Криптография.md

@@ -6,7 +6,7 @@
 - **Исключение атак повторного воспроизведения**: каждый пакет снабжён уникальными идентификатором, что приводит к невозможности проведения replay-атак.
 - **Forward Secrecy**: компрометация долговременного ключа или сессионных ключей не приводит к компрометации прошлых сессионных ключей.
 - **Future Secrecy**: компрометация сессионных ключей не приводит к компрометации будущих сессионных ключей.
-- **Исключение различных вариаций статистического анализа**: сессионные ключи регулярно проходят ротацию, в соединение подмешиваются "шумовые" пакеты, а в пакеты с реальными данными подмешиваются "шумовые данные", что размывает статистические характеристики и затрудняет анализ, предотвращая разные формы атак на основе шифротекста.
+- **Исключение различных вариаций статистического анализа**: сессионные ключи регулярно проходят ротацию, в соединение подмешиваются "шумовые" пакеты, а в пакеты с реальными данными подмешиваются "шумовые данные", что размывает статистические характеристики и затрудняет анализ, предотвращая разные формы атак на основе шифротекста. Также шум может быть добавлен на уровне транспортного адаптера.
 
 В рамках криптографической системы стадиума существуют несколько понятий, таких как:
 

Пакет.md

@@ -1,10 +1,10 @@
 # Пакет
 
-Пакет это физическая единица информации протокола стадиум. Пакет состоит из идентификатора потока, заголовка и тела. Применимость шифрования как такового, криптографические алгоритмы и алгоритмы сжатия - определяются потоком, по которому передаётся пакет. В шифрованном потоке, заголовок шифруется вместе с телом.
+Пакет это логическая единица информации протокола стадиум. Пакет состоит из идентификатора потока, заголовка и тела. Применимость шифрования как такового, криптографические алгоритмы и алгоритмы сжатия - определяются потоком, по которому передаётся пакет. В шифрованном потоке, заголовок шифруется вместе с телом.
 
 В заголовке пакета находятся такие данные как: код аутентификации пакета (Packet Authentication Code), который представляет из себя хэш от обработанных данных и если пакет передаётся по шифрованному потоку, то он дополнительно подписан; флаги наличия сжатия, шумовых данных, идентификатора и флаг системного события; и идентификатор пакета, который присутствует лишь в случае, если в потоке включено подтверждение доставки и/или к данному пакету предполагается ответ.
 
-В теле пакета содержутся произвольные данные и шум (если включен на уровне потока). Ограничения на максимальный размер тела пакета протокола стадиум нет, но оно может быть опционально задано на этапе рукопожатия и/или подстраиваться под максимальный размер пакета протокола транспортного уровня. В таком случае, если данные не помещаются в лимит транспорта - они разбивается на несколько стадиумных пакетов, которые представляют из себя пачку пакетов. При попытке отправки приложением данных, превышающих лимит размера тела пакета, на стороне отправляющего узла должна возникнуть ошибка. Узел-получатель не должен предполагать, что получает данные валидной длинны и должен производить проверки самостоятельно.
+В теле пакета содержутся произвольные данные и шум (если включен на уровне потока). Ограничения на максимальный размер тела пакета в рамках протокола нет, но оно может быть опционально задано на этапе рукопожатия, в том числе оно может быть подстроено под максимальный размер пакета транспортного адаптера. Таким-же образом может быть опционально задано максимально количество суб-пакетов. Если данные не помещаются в лимит адаптера - они разбиваются на несколько суб-пакетов, которые представляют из себя пачку и логически являются одним пакетом протокола стадиум. При попытке отправки приложением данных, превышающих лимит размера тела пакета, на стороне отправляющего узла должна возникнуть ошибка. Узел-получатель не должен предполагать, что получает данные валидной длинны/допустимое число суб-пакетов и должен производить проверки самостоятельно.
 
 
 ## Ориентировочная схема структуры пакета

Поток.md

@@ -2,8 +2,8 @@
 
 Поток - это логический канал для передачи пакетов, существующий в пределах конкретной сессии. Потоки создаются и уничтожаются по инициативе клиента. Сервер может ограничивать создание новых потоков и в нормальных условиях не должен уничтожать потоки. При создании сессии всегда создаётся один поток. Клиенты могут создавать потоки только в пределах собственной сессии.
 
-У потока есть некий набор параметров, часть из которых он разделяет с сессией. У каждого потока есть свой уникальный идентификатор (StreamId) и секрет (StreamSecret), последний задаётся на этапе создания нового потока. Поток может быть как "шифрованным", так и "нешифрованным", что влияет на формат пакетов: в нешифрованном потоке, идентификатор потока статичен, а в шифрованном - обновляется и уникален для каждого пакета. Шифрованный поток может находиться в одном из двух состояний: "работает" или "рассинхронизирован", а нешифрованный только в первом. В случае непредвиденного нарушения работоспособности шифрованного потока, он переходит в состояние "рассинхронизирован", а вернуть его обратно в состояние "работает" клиент может путём отправки серверу пакета со специальным видом рукопожатия, содержащим StreamSecret. <!--TODO: мб написать чуть подробнее, что за "непредвиденное нарушение"-->
+У потока есть некий набор параметров, часть из которых он разделяет с сессией. У каждого потока есть свой уникальный идентификатор (StreamId) и секрет (StreamSecret), последний задаётся на этапе создания нового потока. У потока есть параметры криптографии и шума. Поток может быть как "шифрованным", так и "нешифрованным", что влияет на формат пакетов: в нешифрованном потоке, идентификатор потока статичен, а в шифрованном - обновляется и уникален для каждого пакета. Шифрованный поток может находиться в одном из двух состояний: "работает" или "рассинхронизирован", а нешифрованный только в первом. В случае непредвиденного нарушения работоспособности шифрованного потока, он переходит в состояние "рассинхронизирован", а вернуть его обратно в состояние "работает" клиент может путём отправки серверу пакета со специальным видом рукопожатия, содержащим StreamSecret. <!--TODO: мб написать чуть подробнее, что за "непредвиденное нарушение"-->
 
-Значительная часть функциональности протокола, в том числе касающаяся криптографии, опциональна в том смысле, что может не использоваться в рамках отдельного потока. К примеру, в нём может быть не только настроено количество шума, но и полностью отключен. Таким-же образом, коммуникация может происходить вовсе без шифрования, что может быть полезно, например, для снижения нагрузки на железо, когда протокол транспортного уровня уже обеспечивает требуемый уровень приватности. Поток также может гарантировать последовательность отправки пакетов и информирование в случае недоставки или повреждения пакета, но это остаётся на усмотрение клиента и отключаемо в случае ненадобности.
+Значительная часть функциональности протокола, в том числе касающаяся криптографии, опциональна в том смысле, что может не использоваться в рамках отдельного потока. К примеру, в нём может быть не только настроено количество шума, но и полностью отключен. Таким-же образом, коммуникация может происходить вовсе без шифрования, что может быть полезно, например, для снижения нагрузки на железо, когда протокол используемый транспортным адаптером уже обеспечивает требуемый уровень приватности. У шума может быть настроен "характер", т.е. его статистические характеристики. Поток также может гарантировать последовательность отправки пакетов и информирование в случае недоставки или повреждения пакета, но это остаётся на усмотрение клиента и отключаемо в случае ненадобности.
 
-Поток привязан к транспортному протоколу, по которому осуществляется физическая передача пакетов и существует в рамках жизни сессии. Один транспортный протокол может использоваться сразу несколькими потоками. Все потоки двунаправленны, т.е. пакеты могут отправляться как от клиента к серверу, так и наоборот.
+Поток привязан к транспортному а, по которому осуществляется физическая передача пакетов и существует в рамках жизни сессии. Один транспортный адаптер может использоваться сразу несколькими потоками. Все потоки двунаправленны, т.е. пакеты могут отправляться как от клиента к серверу, так и наоборот.

Сериализация.md

@@ -1,6 +1,6 @@
-# Сериализация и формат LBM
+# Сериализация и формат KLV
 
-Данный формат сериализации используются в теле системных событий и рукопожатии. Данные сериализованные в формат LBM (AKA "данные в формате LBM") являются расположенными последовательно ячейками с ключом, длинной значения и значением, в неопределённом порядке относительно друг-друга. Положение ячеек относительно друг-друга не детерминированно и они могут быть намеренно перемешаны. Отсутствие каких-либо ячеек вообще обозначается единичным нулевым байтом.
+Аббревиатура KLV расшифровывается как "Key-Length-Value" и используются в теле системных событий и рукопожатии. Данные сериализованные в формат KLV (AKA "данные в формате KLV") являются расположенными последовательно ячейками с ключом, длинной значения и значением, в неопределённом порядке относительно друг-друга. Положение ячеек относительно друг-друга не детерминированно и они могут быть намеренно перемешаны. Отсутствие каких-либо ячеек вообще обозначается единичным нулевым байтом.
 
 Ключ является однобайтным числом без знака. Ключ всегда больше нуля. В каждом контексте (контекст системных событий и контекст рукопожатия) есть свой набор выделенных ключей. Все остальные, неиспользуемые ключи при парсинге опускаются. Длинна значения является двухбайтным числом без знака. Если ячейка пуста, то длинна нулевая. Значением является произвольная последовательность байт.
 

Транспортный адаптер.md

@@ -1,11 +1,21 @@
 # Транспортный адаптер
 
-Адаптер представляет из себя нечто, способное вести коммуникацию в рамках конкретного транспортного протокола, преобразовывать передаваемый ему произвольный набор байт в форму, приемлимую транспортным протоколом и корректно воспринимаемую другим адаптером того-же вида, а также выполнять обратное преобразование.
+Адаптер представляет из себя нечто, способное вести коммуникацию в рамках конкретного транспортного протокола, преобразовывать передаваемый ему произвольный набор байт в форму, приемлимую транспортным протоколом и корректно воспринимаемую другим адаптером того-же вида, а также выполнять обратное преобразование. У каждого транспортного адаптера есть собственное кодовое имя, которое позволяет его однозначно идентифицировать.
 
-В рамках базового протокола предписана реализация нескольких адаптеров, для протоколов:
+Транспортный адаптер предоставляет интерфейс для передачи данных в виде блоков, т.е. массивов байт известного размера. У каждого транспортного адаптера есть собственный лимит на максимальный размер блока данных, вне зависимости от того, является-ли низлежащий протокол потоковым.
 
-- UDP
-- TCP
-- HTTP/1.1 (RFC 2616)
-- HTTP/1.1 + TLS 1.3
-- SSH Transport Layer Protocol (RFC 4253)
+Транспортный адаптер, в силу своей природы, может также обеспечивать дополнительный уровень шифрования, а также добавлять "шумовые пакеты" в траффик. Адаптеры должны сами согласовать эти параметры (если нужно).
+
+В рамках базового протокола предписана реализация нескольких адаптеров, реализующих наивные варианты передачи данных по нижележащим протоколам. Предписанных к реализации адаптеров, перечень которых приведён ниже, существует два типа: обязательные и рекомендуемые. Первые обязаны присутствовать в любой реализации, соответствующей спецификации протокола, вторыми допускается пренебречь.
+
+### Обязательные
+
+- DumbU: реализует передачу поверх протокола UDP
+- DumbT: передаёт данные по TCP
+
+### Рекомендуемые
+
+- FirstClass: использует для передачи минималистичный сабсет HTTP/1.1
+- TrashBox:   использует FTP (RFC 959)
+- TLSimp:     использует TLS 1.3 (RFC 8446 и пр.)
+- Pissle:     использует ICMP <!-- Да, название прекрасно, цепочка ассоциаций была следующей: ICMP -> ICBM -> Missle -> Ping Missle -> ... -->