Do i rly need to comment this sheat?
This commit is contained in:
parent
c38d674031
commit
8e70978778
82
DATA TYPES.md
Normal file
82
DATA TYPES.md
Normal file
@ -0,0 +1,82 @@
|
||||
# Типы данных
|
||||
|
||||
Сия спецификация, помимо всего прочего, также определяет некоторые необходимые типы и структуры данных. В данном файле вы найдёте их описание и декларации.
|
||||
|
||||
|
||||
|
||||
#### ID
|
||||
|
||||
Класс, реализующий абстракцию над более конкретными типами идентификаторов. В этой спецификации указывается в качестве типа в тех случаях, когда применим любой из трёх типов.
|
||||
|
||||
```C++
|
||||
class ID {
|
||||
private:
|
||||
uint64_t object_id, server_id;
|
||||
std::string server_domain;
|
||||
public:
|
||||
ID (uint64_t oid, uint64_t sid, std::string sd) {
|
||||
this->object_id = oid;
|
||||
this->server_id = sid;
|
||||
this->server_domain = sd;
|
||||
}
|
||||
LocID GetValue () { return this->object_id; }
|
||||
FedID GetValue () {
|
||||
FedID fid;
|
||||
fid.Object = this->object_id;
|
||||
fid.Server = this->server_id;
|
||||
return fid;
|
||||
}
|
||||
GlobID GetValue () {
|
||||
GlobID gid;
|
||||
gid.Object = this->object_id;
|
||||
gid.Server = this->server_domain;
|
||||
return gid;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### LocID
|
||||
|
||||
Идентификатор локального для конкретного сервера объекта.
|
||||
|
||||
```C++
|
||||
typedef uint64_t LocID;
|
||||
```
|
||||
|
||||
#### FedID
|
||||
|
||||
Идентификатор объекта в пределах федерации.
|
||||
|
||||
```C++
|
||||
typedef struct {
|
||||
uint64_t Object;
|
||||
uint64_t Server;
|
||||
} FedID;
|
||||
```
|
||||
|
||||
#### GlobID
|
||||
|
||||
Идентификатор объекта за пределами федерации.
|
||||
|
||||
```C++
|
||||
typedef struct {
|
||||
uint64_t Object;
|
||||
std::string Server; // Доменное имя целевого сервера
|
||||
} GlobID;
|
||||
```
|
||||
|
||||
#### Power
|
||||
|
||||
Права доступа к какому-либо объекту. Представляет из себя набор следующих флагов:
|
||||
|
||||
- `0b00000000000000000000000000000001`: чтение
|
||||
- `0b00000000000000000000000000000010`: запись
|
||||
- `0b00000000000000000000000000000100`: удаление
|
||||
- `0b10000000000000000000000000000000`: изменение прав доступа
|
||||
- `0b01111111111111111111111111111000`: нераспределено
|
||||
|
||||
Нераспределённые флаги могут быть использованы в SPX.
|
||||
|
||||
```C++
|
||||
typedef uint32_t Power;
|
||||
```
|
@ -2,7 +2,7 @@
|
||||
|
||||
После успешной установки защищённого соединения, происходит обмен характеристиками обоих сторон, AKA "рукопожатие". Запрашивающий соединение отправляет пакет следующего формата:
|
||||
|
||||
`[magic number: 8B][protocol version: 4B][sizes: 1B][reconnection flags: 2B]`
|
||||
`[magic number: 8B][protocol version: 4B][sizes: 1B][crypto params: 2B][reconnection flags: 2B]`
|
||||
|
||||
- Магическое число
|
||||
- _Тип:_ `uint64_t`
|
||||
|
@ -1 +1,49 @@
|
||||
TODO
|
||||
# Список зарезервированных ключей ячеек
|
||||
|
||||
<!-- TODO: сделать папку и там разместить подробное описание некоторых ключей -->
|
||||
|
||||
## Базовые примитивы
|
||||
|
||||
- Data
|
||||
- _Значение:_ `0x01`
|
||||
- _Тип:_ любой
|
||||
- Основные передаваемые данные.
|
||||
- ObjectID
|
||||
- _Значение:_ `0x02`
|
||||
- _Тип:_ `ID`
|
||||
- ID объекта в локальном контексте. Например, ID канала для отправки сообщения.
|
||||
- EventAuthor
|
||||
- _Значение:_ `0x03`
|
||||
- _Тип:_ `LocID` или `FedID`
|
||||
- Источник (автор) события. Например, если клиент отправляет сообщение в канал, то он должен указывать свой айди как значение этой ячейки.
|
||||
- PrevEvent
|
||||
- _Значение:_ `0x04`
|
||||
- _Тип:_ `LocID` или `FedID`
|
||||
- Предыдущее событие, логически связанное с текущим.
|
||||
- NextEvent
|
||||
- _Значение:_ `0x05`
|
||||
- _Тип:_ `LocID` или `FedID`
|
||||
- Следующее событие, логически связанное с текущим.
|
||||
- BatchNumber
|
||||
- _Значение:_ `0x06`
|
||||
- _Тип:_ `uint32_t`
|
||||
- Последовательный номер события в цепочке.
|
||||
- Path
|
||||
- _Значение:_ `0x07`
|
||||
- _Тип:_ `char[]`
|
||||
- Название загружаемого/запрашиваемого файла или URL.
|
||||
- Power
|
||||
- _Значение:_ `0x08`
|
||||
- _Тип:_ `Power`
|
||||
- Права доступа к конкретному объекту.
|
||||
|
||||
## Криптография
|
||||
|
||||
- CryptoAlgo
|
||||
- _Значение:_ `0x11`
|
||||
- _Тип:_ `uint32_t`
|
||||
- Флаги используемых криптографических алгоритм(-ов) для шифрования данных.
|
||||
- CryptoKeyID
|
||||
- _Значение:_ `0x12`
|
||||
- _Тип:_ `uint32_t`
|
||||
- Идентификатор используемого криптографического ключа для шифрования данных.
|
36
OVERVIEW.md
36
OVERVIEW.md
@ -1,6 +1,6 @@
|
||||
# Спецификация протокола Stadium v1.0
|
||||
|
||||
Протокол Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Также является основой для полнофункционального мессенджера Marafon.
|
||||
Протокол Stadium это протокол для безопасной коммуникации общего назначения, работающий поверх любого поддерживаемого транспорта. Данная спецификация описывает лишь базу, поверх которой может быть реализованы расширения (SPX - Stadium Protocol eXtension) для более конкретных нужд. Помимо прочего, данный протокол служит основой для полнофункционального мессенджера Marafon, спецификация расширения которого находится в папке `Marafon SPX`.
|
||||
|
||||
_Здесь описана спецификация базового протокола; документация касательно версии протокола используемой в мессенджере размещена в другом репозитории._
|
||||
|
||||
@ -13,6 +13,8 @@ _Здесь описана спецификация базового прото
|
||||
- Совместимость со всеми мажорными оверлейными сетями (Tor, I2P и yggdrasil).
|
||||
- Расширяемость.
|
||||
|
||||
В сей спецификации вы иногда сможете встретить примеры кода и упоминание типов данных языка C++, так как без них обойтись моментами сложно.
|
||||
|
||||
<!-- TODO: какое шифрование, какие алгоритмы, etc. -->
|
||||
|
||||
|
||||
@ -51,9 +53,9 @@ _Здесь описана спецификация базового прото
|
||||
|
||||
Пакеты с событиями всех категорий, кроме явно оговорённых или принадлежащих к надкатегории Server2Client, содержат идентификатор серверной сессии, являющийся четырёхбайтным числом без знака (`uint32_t`).
|
||||
|
||||
Пакеты с событиями всех категорий из надкатегории Client2Server, кроме явно оговорённых, содержат хэш полезной нагрузки, зашифрованный с помощью закрытого ключа подписи клиента. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения ("клиент-сервер" или "сервер-сервер").
|
||||
Пакеты с событиями всех категорий, кроме явно оговорённых, содержат хэш полезной нагрузки, зашифрованный с помощью закрытого ключа подписи отправляющего. Этот подписанный хэш гарантирует достоверность полезной нагрузки на уровне прямого подключения ("клиент-сервер" или "сервер-сервер").
|
||||
|
||||
Данные (AKA "полезная нагрузка") могут быть представлены в формате фиксированной схемы или в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" и могут быть расположены в произвольном порядке относительно друг-друга. Формат целиком зависит от типа события. Все неизвестные ключи при парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид:
|
||||
Данные (AKA "полезная нагрузка") могут быть представлены в формате фиксированной схемы или в формате KLDR ("Key-Length-Data-Repeat"), которые являются расположенными последовательно парами "ключ-значение" и могут быть расположены в произвольном порядке относительно друг-друга. Применяемый формат зависит от типа события, но чаще всего это KLDR. Все неизвестные ключи при его парсинге игнорируются. Одна пара (AKA "ячейка") имеет следующий вид:
|
||||
|
||||
`[key][data length][data]`
|
||||
|
||||
@ -71,7 +73,7 @@ _Здесь описана спецификация базового прото
|
||||
|
||||
### Зарезервированные события
|
||||
|
||||
Некоторые категории событий зарезервированы под нужды базового протокола или просто для событий определённого рода. Второе носит рекомендательный характер; вы также можете использовать другие диапазоны для тех-же целей.
|
||||
Некоторые категории событий зарезервированы под нужды базового протокола или просто для событий определённого рода. Второе носит рекомендательный характер; вы также можете использовать иные диапазоны для тех-же целей.
|
||||
|
||||
Все из зарезервированных типов помещаются в минимальную размерность типа события (т.е. по одному байту на категорию и подкатегорию). Ниже приведены диапазоны зарезервированных значений.
|
||||
|
||||
@ -93,9 +95,9 @@ _Здесь описана спецификация базового прото
|
||||
|
||||
- `0x00`
|
||||
- Запрещено к использованию.
|
||||
- `0x01-0x20` (включительно)
|
||||
- `0x01-0x10` (включительно)
|
||||
- Базовые примитивы.
|
||||
- `0x21-0x2F` (включительно)
|
||||
- `0x11-0x1F` (включительно)
|
||||
- Для нужд криптографии.
|
||||
|
||||
Подробное описание зарезервированных ключей есть в файле `KLDR RESERVED KEYS.md`.
|
||||
@ -132,21 +134,33 @@ _Здесь описана спецификация базового прото
|
||||
10. ЦК проверяет подпись ППН на валидность. Допустим, что подпись верна.
|
||||
11. ЦК проверяет подпись основных данных, на предмет соответствия подписи клиента-отправителя и совершает релевантные действия.
|
||||
|
||||
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, соединение разрывается, а администратор сервера и владелец учётной записи уведомляются об инциденте.
|
||||
Каждый принятый сервером пакет, содержащий хэш полезной нагрузки, должен проверяться на соответствие подписи, путём расшифровки этого хэша открытом ключом подписи и последующего сравнения с реальным хэшем полезной нагрузки. Если сервер обнаруживает, что подпись неверна - сервер отвечает ошибкой, добавляет запись в журнал об инциденте, а обрабатываемый пакет игнорируется.
|
||||
|
||||
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, может быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он должен оповестить пользователя.
|
||||
Каждый принятый клиентом пакет, содержащий хэш полезной нагрузки, должен быть проверен на соответствие подписи. Если клиент обнаруживает, что подпись неверна - он уведомляет об этом пользователя, а обрабатываемый пакет игнорируется.
|
||||
|
||||
<!-- TODO: решить: как и нужно-ли, чтобы сервер являлся средой нулевого доверия в плане передачи подписей пользователей (скорее всего "Да.") -->
|
||||
|
||||
Полезная нагрузка пакета может быть проверена на целостность сервером или клиентом с использованием хэша, но данная проверка может быть отключена, по усмотрению владельца сервера или пользователя клиента.
|
||||
|
||||
Если при проверке ID серверной сессии обнаруживается несоответствие - сервер отвечает ошибкой, соединение разрывается.
|
||||
|
||||
|
||||
|
||||
## Система идентификаторов
|
||||
|
||||
Практически каждый объект в Stadium имеет свой уникальный идентификатор, по которому к нему (объекту) следует обращаться. Идентификаторы делятся на два типа: локальные и федеративные.
|
||||
|
||||
Первый тип является восьмибайтным числом без знака (`uint64_t`). Валидный объект не может иметь ID равный нулю.
|
||||
|
||||
Второй тип является структурой из двух восьмибайтных чисел без знака, кои являют из себя ID объекта и ID федерируемого сервера соответственно.
|
||||
|
||||
ID федерируемого сервера определяется сервером при первой попытке коммуникации и ассоциировано с его подписью, списком доменов и IP-адресов.
|
||||
|
||||
Сервер должен проверять идентификатор на валидность и отвергать его, если он не валиден в текущем контексте.
|
||||
|
||||
|
||||
|
||||
## Список ToDo (To Document)
|
||||
|
||||
- Механизм пользовательский сессий, клиентские подписи и базовая аутентификация
|
||||
- Механизм пользовательских сессий, клиентские подписи и базовая аутентификация
|
||||
- Механизм синхронизации ключей для сквозного шифрования между юзерами
|
||||
- Манипуляции с файлами (скачивание/загрузка)
|
||||
- Стриминг аудио и видео
|
3
SPX/Marafon/README.md
Normal file
3
SPX/Marafon/README.md
Normal file
@ -0,0 +1,3 @@
|
||||
# Marafon SPX
|
||||
|
||||
_Расширение протокола Stadium для мессенджера Marafon._
|
Loading…
Reference in New Issue
Block a user