# Анализ и реализация клиента для Project Colette V53

Этот документ представляет подробный технический разбор процесса подключения к серверу Project Colette V53. Он анализирует криптографическое рукопожатие, структуру пакетов и логику обмена сообщениями, реализованную в Python-клиенте `main.py`.

## [*] Основные концепции

Протокол обмена данными — это пользовательский протокол, работающий поверх стандартного TCP. Шифрование построено с использованием криптографической библиотеки **NaCl** (в коде C# упоминается как `TweetNaCl`), которая предоставляет:
-   **Асимметричное шифрование**: `Curve25519` для обмена ключами через эллиптическую кривую Диффи-Хеллмана (ECDH).
-   **Симметричное шифрование**: `XSalsa20-Poly1305` для потокового шифрования после установления сессии.
-   **Хеширование**: `Blake2b` для генерации одноразовых номеров (nonce).

Каждое сообщение (пакет) в протоколе предваряется 7-байтным заголовком:
-   **ID сообщения** (2 байта): Идентификатор типа сообщения.
-   **Длина полезной нагрузки** (3 байта): Длина предстоящих данных.
-   **Версия** (2 байта): Версия сообщения.

## [!] Пошаговый разбор процесса подключения

Процесс от первоначального подключения до полностью установленной зашифрованной сессии включает обмен четырьмя ключевыми пакетами.

---

### **Шаг 1: `ClientHello` (ID: 10100)**

-   **Направление**: Клиент -> Сервер
-   **Шифрование**: Нет

Это самый первый пакет, который клиент отправляет после установления TCP-соединения. Его единственная цель — инициировать сессию на сервере и сообщить о готовности начать рукопожатие. Полезная нагрузка этого пакета не имеет значения для криптографии и может быть заполнена нулями.

---

### **Шаг 2: `LoginMessage` (ID: 10101)**

-   **Направление**: Клиент -> Сервер
-   **Шифрование**: Асимметричное (`Box`)

Это ключевой пакет от клиента, где происходит основная магия обмена ключами.

#### **Подготовка на стороне клиента (перед отправкой):**
1.  **Ключ сервера**: Клиент использует статический `server_public_key` сервера, который известен заранее (извлечен из исходного кода сервера).
2.  **Ключи клиента**: Клиент генерирует новую, **эфемерную (временную)** пару ключей `Curve25519` — `client_public_key` и `client_private_key`. Эта пара будет использоваться только для текущей сессии.
3.  **Общий секрет (`s`)**: Клиент немедленно вычисляет предварительный общий секрет (`shared_secret` или `s`), используя свой новый приватный ключ и публичный ключ сервера. Это стандартная операция ECDH. В `PyNaCl` это делается с помощью `Box.beforenm(server_public_key, client_private_key)`. Этот секрет `s` понадобится для расшифровки ответа сервера.
4.  **Nonce клиента (`RNonce`)**: Клиент генерирует 24 случайных байта, `client_nonce`. Сервер называет это `RNonce` (Nonce получателя). Это критически важная часть рукопожатия.

#### **Структура и передача пакета:**
Пакет `10101` состоит из двух частей:
1.  **Публичный ключ клиента** (32 байта): Отправляется в открытом виде.
2.  **Зашифрованная полезная нагрузка**:
    -   **Данные для шифрования**: Открытый текст для шифрования содержит:
        1.  Временный сеансовый ключ (24 байта, генерируется клиентом, но игнорируется сервером).
        2.  `client_nonce` (`RNonce`) (24 байта).
        3.  Фактические данные для входа (ID аккаунта, версия клиента и т.д.), сериализованные в байтовый поток.
    -   **Nonce для шифрования**: Nonce для этой операции вычисляется как хеш публичных ключей: `blake2b(client_public_key + server_public_key)`.
    -   **Процесс шифрования**: Вышеуказанные данные шифруются с помощью `Box(client_private_key, server_public_key).encrypt(...)`.

---

### **Шаг 3: `ServerHello` (ID: 20100)**

-   **Направление**: Сервер -> Клиент
-   **Шифрование**: Асимметричное (`Box`)

Это ответ сервера, который завершает асимметричную фазу рукопожатия.

#### **Процесс расшифровки на стороне клиента:**
1.  **Вычисление Nonce**: Чтобы расшифровать этот пакет, клиент должен использовать тот же `nonce`, который использовал сервер. Сервер вычисляет его по формуле: `blake2b(RNonce + client_public_key + server_public_key)`. У клиента уже есть все три компонента: он сам сгенерировал `RNonce` и знает оба публичных ключа.
2.  **Процесс расшифровки**: Расшифровка выполняется с использованием ранее вычисленного общего секрета `s`. Формула: `Box.open_afternm(payload, nonce, shared_secret)`.

#### **Содержимое расшифрованного пакета:**
Внутри находятся два ключевых элемента для всей будущей коммуникации:
1.  **Финальный сеансовый ключ (`session_key`)** (32 байта): Это симметричный ключ, который будет использоваться для шифрования всех последующих сообщений.
2.  **Nonce сервера (`SNonce`)** (24 байта): Этот nonce будет основой для шифрования сообщений, идущих **от сервера к клиенту**.

---

### **Шаг 4: Переход к симметричному шифрованию и `LoginOk` (ID: 20104)**

-   **Направление**: Сервер -> Клиент
-   **Шифрование**: Симметричное (`SecretBox`)

После получения `ServerHello` криптографическая сессия считается полностью установленной. Все последующие пакеты шифруются симметрично с использованием `SecretBox` и `session_key`.

#### **Логика Nonce (`NextNonce`)**
Ключевой особенностью протокола является то, что nonce увеличивается **на 2** перед каждой операцией шифрования или дешифрования. Функция `next_nonce` в коде точно воспроизводит эту логику на стороне сервера.

#### **`LoginOk`**
Это первый пакет, который клиент получает в зашифрованном виде.
1.  **Получить Nonce**: Клиент берет `SNonce`, полученный на предыдущем шаге.
2.  **Увеличить Nonce**: Он применяет к нему логику `next_nonce` (увеличивая его на 2).
3.  **Расшифровать**: Он расшифровывает пакет с помощью `SecretBox(session_key).decrypt(payload, nonce)`.

Успешная расшифровка `LoginOk` подтверждает, что весь процесс прошел корректно, и клиент теперь находится в полностью зашифрованной сессии с сервером. Этот пакет содержит данные о созданном аккаунте (ID, токен и т.д.).