Cyclone-Team/stadium-proto
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Правки по сессии и структуре пакета

Browse Source
This commit is contained in:
Shr3dd3r 2023-10-28 05:05:32 +03:00
parent c6b88359f9
commit 75630f92cf
4 changed files with 57 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
DATA TYPES.md
View File

@ -12,52 +12,51 @@
enum CryptoAlgoType: uint8_t { enum CryptoAlgoType: uint8_t {
Reserved = 0, Reserved = 0,
// Checksums // Checksums
CRC_16 = 10, CRC_16 = 11,
CRC_32 = 11, CRC_32,
CRC_64 = 12, CRC_64,
fletcher_8 = 13, fletcher_8,
fletcher_16 = 14, fletcher_16,
fletcher_32 = 15, fletcher_32,
Adler_32 = 16, Adler_32,
// Non-crypto hashes // Non-crypto hashes
Pearson_8 = 30,
Murmur64A = 31, Murmur64A = 31,
Murmur3_32 = 32, Murmur3_32,
Murmur3_128 = 33, Murmur3_128,
Spooky_128 = 34, Spooky_128,
// Cryptographic hashes // Cryptographic hashes
BLAKE2b = 60, BLAKE2b = 61,
BLAKE3 = 61, BLAKE3,
GOST = 62, GOST,
HAS160 = 63, HAS160,
HAVAL = 64, HAVAL,
MD2 = 65, MD2,
MD5 = 66, MD5,
RIPEMD = 67, RIPEMD,
SHA1 = 68, SHA1,
SHA2 = 69, SHA2,
SHAKE128 = 70, SHAKE128,
SHAKE256 = 71, SHAKE256,
Skein = 72, Skein,
Snefru = 73, Snefru,
Streebog = 74, Streebog,
Tiger = 75, Tiger,
Whirlpool = 76, Whirlpool,
// Symmetric key block ciphers // Symmetric key block ciphers
Blowfish = 130, Blowfish = 131,
Twofish = 131, Twofish,
TripleDES_CBC = 132, TripleDES_CBC,
AES_GCM = 133, // AKA Rijndael AES_GCM, // AKA Rijndael
AES_CBC = 134, AES_CBC,
AES_CTR = 135, AES_CTR,
Camellia = 136, Camellia,
Salsa20 = 137, Salsa20,
CAST5 = 138, CAST5,
CAST6 = 139, CAST6,
Kuznyechik = 140, Kuznyechik,
MESH = 141, MESH,
Akelarre = 142, Akelarre,
RC6 = 143, RC6,
// TODO // TODO
}; };
``` ```

4
KLDR RESERVED KEYS.md
View File

@ -39,10 +39,10 @@
- _Значение:_ `0x08` - _Значение:_ `0x08`
- _Тип:_ `Power` - _Тип:_ `Power`
- Права доступа к конкретному объекту. - Права доступа к конкретному объекту.
- ServerSession <!--- ServerSession
- _Значение:_ `0x09` - _Значение:_ `0x09`
- _Тип:_ `uint32_t` - _Тип:_ `uint32_t`
- Идентификатор серверной сессии. В случае с аутентифицированным соединением, его присутствие обязательно. - Идентификатор серверной сессии. В случае с аутентифицированным соединением, его присутствие обязательно.-->

20
OVERVIEW.md
View File

@ -4,10 +4,10 @@ Stadium это протокол для безопасной коммуникац
Основной фокус при работе над сим проектом идёт на: Основной фокус при работе над сим проектом идёт на:
- Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр. (Reject HTML+JSON, return to binary)); - Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр.);
- Устойчивость к цензуре; - Устойчивость к цензуре;
- Федеративность; - Федеративность;
- Поддержка гибкого сквозного шифрования. (возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать; - Поддержка гибкого сквозного шифрования, т.е. возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать;
- Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil); - Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil);
- Расширяемость. - Расширяемость.
@ -48,11 +48,13 @@ Stadium это протокол для безопасной коммуникац
Все категории вместе являются типом события. Значение типа - это шестнадцатеричное число, которое указывается в начале пакета. Все категории вместе являются типом события. Значение типа - это шестнадцатеричное число, которое указывается в начале пакета.
Пакеты с событиями всех категорий, кроме явно оговорённых, содержат хэш полезной нагрузки, зашифрованный с помощью закрытого ключа подписи отправляющего. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения ("клиент-сервер" или "сервер-сервер"). Пакеты с событиями всех категорий содержат хэш полезной нагрузки размером равно или более 16 байт, зашифрованный с помощью закрытого ключа подписи отправляющего. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения ("клиент-сервер" или "сервер-сервер").
Идентификатор события является двухбайтным числом без знака (`uint16_t`) и служит для определения отношения запросов к ответам, при использовании асинхронной схемы передачи данных. Идентификатор серверной сессии является четырёхбайтным числом без знака (`uint32_t`). Подробнее про сессии - в `SESSIONS.md`.
Данные (AKA "полезная нагрузка") могут быть представлены в формате фиксированной схемы или в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" в неопределённом порядке относительно друг-друга. Сервер и клиент могут перемешивать ячейки перед отправкой намеренно. Применяемый формат зависит от типа события, но чаще всего это KLDR. Все неизвестные ключи при его парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид: Идентификатор события является двухбайтным числом без знака (`uint16_t`) и служит для определения отношения запросов к ответам во время асинхронного обмена пакетами.
Данные (AKA "полезная нагрузка") представлены в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" в неопределённом порядке относительно друг-друга. Сервер и клиент могут перемешивать ячейки перед отправкой намеренно. Конкретные используемые ключи зависит от типа события. Все неизвестные ключи при его парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид:
`[key][data length][data]` `[key][data length][data]`
@ -60,13 +62,13 @@ Stadium это протокол для безопасной коммуникац
`[cell_1][cell_2][cell_3]...[cell_n]` `[cell_1][cell_2][cell_3]...[cell_n]`
Ключ и длинна данных являются шестнадцатеричными числами, размерность которых фиксирована и составляет 8 и 16 бит соответственно. Полезная нагрузка не может отсутствовать полностью, а ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём. Ключ и длинна данных являются шестнадцатеричными числами, размерность которых фиксирована и составляет 8 и 16 бит соответственно. Ключ не может являться нулём. Если значение конкретной пары пусто, то длинна данных должна быть нулём. Если полезная нагрузка отсутствует целиком, то она заменяется на один нулевой байт.
Исходя из всего вышеописанного, итоговая примерная структура пакета выглядит следующим образом: Исходя из всего вышеописанного, минимальный размер пакета составляет 21 байт, а его итоговая структура выглядит следующим образом:
`[category][subcategory][event id: 2B][payload hash: ~B][payload: >0B]` `[category: 1B][subcategory: 1B][session id: 4B][event id: 2B][payload hash: >16B][payload: >0B]`
Размер пакета не нормирован и ответственность за его менеджмент остаётся на транспортном уровне. Размер полезной нагрузки определяется сервером, к которому происходит подключение, на этапе рукопожатия. Максимальный размер пакета не нормирован и ответственность за его менеджмент остаётся на транспортном уровне. Максимальный размер полезной нагрузки определяется сервером, к которому происходит подключение, на этапе рукопожатия.
P.S.: _эталонная реализация Stadium будет использовать общий универсальный интерфейс, который, в свою очередь, заворачивать все данные в релевантный протокол транспортного уровня._ P.S.: _эталонная реализация Stadium будет использовать общий универсальный интерфейс, который, в свою очередь, заворачивать все данные в релевантный протокол транспортного уровня._

8
SESSIONS.md
View File

@ -52,12 +52,10 @@
## Серверные сессии и их идентификаторы ## Серверные сессии и их идентификаторы
При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента. При подключении клиента к серверу, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с параметрами подключения, установленных на этапе рукопожатия. Клиент и сервер обязаны прилагать назначенный ID серверной сессии к каждому пакету.
После успешной аутентификации, клиент обязан прилагать назначенный ему ID серверной сессии к каждому пакету.
Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается. Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.
Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях. Идентификатор серверной сессии всегда уникален, по отношению к другим активным сессиям, и никогда не равен нулю.
Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию. Если у клиента есть несколько подключений, то все они должны быть снабжены единым серверным идентификатором.