Глава 1. Архитектура Zero-Knowledge: Почему сервер должен быть слепым?

В мире, где данные — это новая нефть, большинство мессенджеров строят свою архитектуру вокруг хранения. Они хранят вашу историю переписки, ваши контакты и метаданные, чтобы обеспечить удобство: синхронизацию между устройствами и поиск.

GuardianT идет от обратного. Мы строим архитектуру вокруг отсутствия знаний.

1.1. Модель угроз: Кому нельзя доверять?

Традиционная модель безопасности (Telegram, WhatsApp) предполагает доверие к двум узлам:

1. Серверу (он обещает не читать переписку, хотя имеет метаданные).
2. Операционной системе смартфона (Android/iOS), которая контролирует экран, клавиатуру и буфер обмена.

Мы считаем оба этих узла скомпрометированными по умолчанию.

Вектор атаки через сервер

Даже при наличии End-to-End шифрования (E2EE), сервер знает: КТО пишет, КОМУ и КОГДА. Это называется метаданные. На основе метаданных строятся социальные графы, которые могут рассказать о человеке больше, чем текст его сообщений.

1.2. Концепция «Слепого курьера»

Архитектура GuardianT реализует принцип Trustless (отсутствие необходимости в доверии). Сервер выполняет роль «горячей картошки»: он должен как можно быстрее избавиться от полученных данных.

Жизненный цикл сообщения:

1. Alice (ESP8266) шифрует сообщение общим секретным ключом.
2. Server получает зашифрованный блоб (Blob).
3. Server держит его в оперативной памяти (RAM).
4. Bob (ESP8266) забирает блоб.
5. Server перезаписывает ячейку памяти нулями.

1.3. Реализация протокола (Code Review)

В текущей версии для ESP8266 мы используем надежный HTTP-транспорт и JSON. Это позволяет устройству легко работать через любые прокси и NAT, используя стандартные порты.

Отправка сообщения (C++ / ArduinoJson)

Сервер получает JSON, где encrypted_data — это "черный ящик" (Base64 строка). Серверу нужен только to_device для маршрутизации. Он не может заглянуть внутрь encrypted_data.

Вот реальный код из main.cpp, отвечающий за упаковку и отправку:

void sendToVDS(String targetUin, String encryptedData) {
    // ... инициализация HTTP клиента ...
    
    JsonDocument doc;
    doc["to_device"] = targetUin;       // Открытый заголовок для маршрутизации
    doc["encrypted_data"] = encryptedData; // AES-256 Encrypted Blob (Base64)
    
    String requestBody;
    serializeJson(doc, requestBody);
    
    // Отправляем POST запрос на сервер
    int httpCode = http.POST(requestBody);
    
    // ... обработка ответа ...
}

Логика сервера (Python / FastAPI)

Серверная часть намеренно примитивна. Она не умеет "читать". Её задача — переложить байты из сокета А в сокет Б.

# Server/core/router.py

async def handle_incoming_blob(header: PacketHeader, blob: bytes):
    """
    Сервер принимает данные, но не валидирует их содержимое.
    Для сервера это просто поток байт.
    """
    
    # 1. Проверка TTL (Time To Live)
    if header.timestamp < (now() - MAX_DELAY):
        return DropPacket("Packet too old")

    # 2. Сохранение в In-Memory хранилище (Redis)
    # Мы используем EXPIRE, чтобы данные гарантированно исчезли
    # даже при сбое сервера.
    await redis.set(
        name=f"msg:{header.session_hash}",
        value=blob,
        ex=60  # Удалить через 60 секунд!
    )
    
    # Никаких логов в базу данных (SQL/Mongo) не пишется.

1.4. Криптография: AES-256

Для шифрования сообщений на микроконтроллерах ESP8266 мы используем стандарт AES-256 CBC.

1. Надежность: AES-256 является золотым стандартом симметричного шифрования.
2. Реализация: Мы используем библиотеку AESLib, которая обеспечивает корректное дополнение блоков (Padding) и использование случайного вектора инициализации (IV) для каждого сообщения.

«Криптография надежна лишь тогда, когда ключи находятся в руках пользователей, а не администраторов сервера».