Правки по сессии и структуре пакета
This commit is contained in:
parent
c6b88359f9
commit
75630f92cf
@ -12,52 +12,51 @@
|
||||
enum CryptoAlgoType: uint8_t {
|
||||
Reserved = 0,
|
||||
// Checksums
|
||||
CRC_16 = 10,
|
||||
CRC_32 = 11,
|
||||
CRC_64 = 12,
|
||||
fletcher_8 = 13,
|
||||
fletcher_16 = 14,
|
||||
fletcher_32 = 15,
|
||||
Adler_32 = 16,
|
||||
CRC_16 = 11,
|
||||
CRC_32,
|
||||
CRC_64,
|
||||
fletcher_8,
|
||||
fletcher_16,
|
||||
fletcher_32,
|
||||
Adler_32,
|
||||
// Non-crypto hashes
|
||||
Pearson_8 = 30,
|
||||
Murmur64A = 31,
|
||||
Murmur3_32 = 32,
|
||||
Murmur3_128 = 33,
|
||||
Spooky_128 = 34,
|
||||
Murmur3_32,
|
||||
Murmur3_128,
|
||||
Spooky_128,
|
||||
// Cryptographic hashes
|
||||
BLAKE2b = 60,
|
||||
BLAKE3 = 61,
|
||||
GOST = 62,
|
||||
HAS160 = 63,
|
||||
HAVAL = 64,
|
||||
MD2 = 65,
|
||||
MD5 = 66,
|
||||
RIPEMD = 67,
|
||||
SHA1 = 68,
|
||||
SHA2 = 69,
|
||||
SHAKE128 = 70,
|
||||
SHAKE256 = 71,
|
||||
Skein = 72,
|
||||
Snefru = 73,
|
||||
Streebog = 74,
|
||||
Tiger = 75,
|
||||
Whirlpool = 76,
|
||||
BLAKE2b = 61,
|
||||
BLAKE3,
|
||||
GOST,
|
||||
HAS160,
|
||||
HAVAL,
|
||||
MD2,
|
||||
MD5,
|
||||
RIPEMD,
|
||||
SHA1,
|
||||
SHA2,
|
||||
SHAKE128,
|
||||
SHAKE256,
|
||||
Skein,
|
||||
Snefru,
|
||||
Streebog,
|
||||
Tiger,
|
||||
Whirlpool,
|
||||
// Symmetric key block ciphers
|
||||
Blowfish = 130,
|
||||
Twofish = 131,
|
||||
TripleDES_CBC = 132,
|
||||
AES_GCM = 133, // AKA Rijndael
|
||||
AES_CBC = 134,
|
||||
AES_CTR = 135,
|
||||
Camellia = 136,
|
||||
Salsa20 = 137,
|
||||
CAST5 = 138,
|
||||
CAST6 = 139,
|
||||
Kuznyechik = 140,
|
||||
MESH = 141,
|
||||
Akelarre = 142,
|
||||
RC6 = 143,
|
||||
Blowfish = 131,
|
||||
Twofish,
|
||||
TripleDES_CBC,
|
||||
AES_GCM, // AKA Rijndael
|
||||
AES_CBC,
|
||||
AES_CTR,
|
||||
Camellia,
|
||||
Salsa20,
|
||||
CAST5,
|
||||
CAST6,
|
||||
Kuznyechik,
|
||||
MESH,
|
||||
Akelarre,
|
||||
RC6,
|
||||
// TODO
|
||||
};
|
||||
```
|
||||
|
||||
@ -39,10 +39,10 @@
|
||||
- _Значение:_ `0x08`
|
||||
- _Тип:_ `Power`
|
||||
- Права доступа к конкретному объекту.
|
||||
- ServerSession
|
||||
<!--- ServerSession
|
||||
- _Значение:_ `0x09`
|
||||
- _Тип:_ `uint32_t`
|
||||
- Идентификатор серверной сессии. В случае с аутентифицированным соединением, его присутствие обязательно.
|
||||
- Идентификатор серверной сессии. В случае с аутентифицированным соединением, его присутствие обязательно.-->
|
||||
|
||||
|
||||
|
||||
|
||||
20
OVERVIEW.md
20
OVERVIEW.md
@ -4,10 +4,10 @@ Stadium это протокол для безопасной коммуникац
|
||||
|
||||
Основной фокус при работе над сим проектом идёт на:
|
||||
|
||||
- Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр. (Reject HTML+JSON, return to binary));
|
||||
- Снижение оверхэдов, по сравнению с классическими решениями (Matrix, Discord, WhatsApp, пр.);
|
||||
- Устойчивость к цензуре;
|
||||
- Федеративность;
|
||||
- Поддержка гибкого сквозного шифрования. (возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать;
|
||||
- Поддержка гибкого сквозного шифрования, т.е. возможность как клиенту так и серверу выбирать, какие криптографические алгоритмы использовать;
|
||||
- Совместимость со всеми мажорными оверлейными сетями (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]`
|
||||
|
||||
@ -60,13 +62,13 @@ Stadium это протокол для безопасной коммуникац
|
||||
|
||||
`[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 будет использовать общий универсальный интерфейс, который, в свою очередь, заворачивать все данные в релевантный протокол транспортного уровня._
|
||||
|
||||
|
||||
@ -52,12 +52,10 @@
|
||||
|
||||
## Серверные сессии и их идентификаторы
|
||||
|
||||
При аутентификации клиента на сервере, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с текущим подключением клиента.
|
||||
|
||||
После успешной аутентификации, клиент обязан прилагать назначенный ему ID серверной сессии к каждому пакету.
|
||||
При подключении клиента к серверу, сервер генерирует и отправляет клиенту уникальный идентификатор серверной сессии, который также ассоциирует с параметрами подключения, установленных на этапе рукопожатия. Клиент и сервер обязаны прилагать назначенный ID серверной сессии к каждому пакету.
|
||||
|
||||
Если при проверке ID серверной сессии в пакете обнаруживается её отсутствие среди пулла серверных сессий - сервер отвечает ошибкой, соединение разрывается.
|
||||
|
||||
Две серверные сессии не должны иметь одинаковое значение ID ни при каких условиях.
|
||||
Идентификатор серверной сессии всегда уникален, по отношению к другим активным сессиям, и никогда не равен нулю.
|
||||
|
||||
Разные подключения одного клиента должны иметь одинаковую ассоциированную сессию.
|
||||
Если у клиента есть несколько подключений, то все они должны быть снабжены единым серверным идентификатором.
|
||||
Loading…
Reference in New Issue
Block a user