TgWitness / Документация
Русский
EnglishРусскийУкраїнськаEspañolPortuguês (Brasil)Türkçeالعربيةفارسیاردوहिन्दीBahasa IndonesiaTiếng Việt简体中文FrançaisDeutschItalianoO‘zbekcha한국어繁體中文Bahasa MelayuPolski日本語ไทยעבריתবাংলা

Справочник / Доказательства

Как устроены доказательства

Объяснение принципов работы цепочки хешей, подписей, контрольных точек и свидетелей с указанием точных формул, используемых верификатором.

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

На местном веб-сайте документации представлены интерактивные примеры по адресу /docs/concepts/, а также инструмент для анализа решений на контрольных точках по адресу /docs/witness/. Все примеры сообщений, количества и задержки являются вымышленными. Хэши в тестовой среде цепочки рассчитываются с помощью алгоритма SHA-256 в браузере. Никакие данные не отправляются в Telegram.

Сообщение изменяется; наблюдения накапливаются#

Диаграмма последовательностиTelegram → Collector: Новое сообщение: Встречаемся в 10:00; Collector → Подписанный журнал: Добавить сообщение.new; Telegram → Collector: Изменение: Встреча в 11:00; Collector → Подписанный журнал: Добавить сообщение.отредактировано; Telegram → Collector: Уведомление об удалении; Collector → Подписанный журнал: Добавить сообщение.deleted; Примечание относительно Подписанный журнал: Сохраняются данные об оригинале, редактировании и удаленииTelegramCollectorПодписанный журналНовое сообщение: Встречаемся в 10:00Добавить сообщение.newИзменение: Встреча в 11:00Добавить сообщение.отредактированоУведомление об удаленииДобавить сообщение.deletedСохраняются данные об оригинале, редактировании иудалении
Схема в текстовом формате
  1. Telegram → Collector: Новое сообщение: Встречаемся в 10:00
  2. Collector → Подписанный журнал: Добавить сообщение.new
  3. Telegram → Collector: Изменение: Встреча в 11:00
  4. Collector → Подписанный журнал: Добавить сообщение.отредактировано
  5. Telegram → Collector: Уведомление об удалении
  6. Collector → Подписанный журнал: Добавить сообщение.deleted
  7. Примечание относительно Подписанный журнал: Сохраняются данные об оригинале, редактировании и удалении

В данной упрощённой последовательности предполагается, что Telegram доставил каждое обновление и что выбранный аккаунт мог его увидеть. Операционные события также фиксируются в журнале. Уведомление об удалении не содержит информации об авторе удаления или точном времени удаления. Повторные доставки считаются отдельными наблюдениями; в журнале не происходит подавления дубликатов.

Что включает в себя хеш#

Наблюдение, кодирование, хеширование и подписание: каждое новое событие содержит хеш предыдущего события.

Прочитайте формулу «изнутри наружу»: C преобразует девять полей в точные байты; SHA-256 вычисляет их дайджест; hex — это формат хранения данного дайджеста. Предыдущий хэш уже находится внутри события. unhex преобразует сохраненный хэш обратно в 32 байта, которые подписывает алгоритм Ed25519.

Схема статической цепочки

Пусть C(ei) — это канонический JSON-файл в кодировке UTF-8, содержащий девять полей событий. Первая запись previous_hash состоит из 64 нулей. Каждая последующая запись содержит шестнадцатеричный хеш предыдущей записи:

hi = hex(SHA256(C(ei)))
σi = Ed25519.Sign(sk,unhex(hi))

Подпись охватывает 32 исходных байта дайджеста. В хеш входят ровно следующие поля: seq, observed_at, source_at, kind, chat_id, message_id, actor_id, payload и previous_hash. Ключи объектов сортируются; пробельные разделители и ASCII-экранирование не используются; NaN и бесконечность отклоняются. См. точные правила кодирования.

Блок-схема64 нулевых символа → Запись 1 / хеш h1; Запись 1 / хеш h1 → Запись 2 содержит h1 / хэш h2; Запись 2 содержит h1 / хэш h2 → Запись 3 содержит теги h2 и h3; Запись 3 содержит теги h2 и h3 → Контрольная точка с подписью: счет 3, заголовок h3 (сохранить в другом месте)64 нулевых символаЗапись 1 / хеш h1Запись 2 содержит h1 /хэш h2Запись 3 содержит тегиh2 и h3Контрольная точка сподписью: счет 3,заголовок h3сохранить в другом месте
Схема в текстовом формате
  1. 64 нулевых символа → Запись 1 / хеш h1
  2. Запись 1 / хеш h1 → Запись 2 содержит h1 / хэш h2
  3. Запись 2 содержит h1 / хэш h2 → Запись 3 содержит теги h2 и h3
  4. Запись 3 содержит теги h2 и h3 → Контрольная точка с подписью: счет 3, заголовок h3 (сохранить в другом месте)
Перейти к предоставленному журналу Что позволяет его распознать
Измените запись № 2, сохранив при этом её хэш Пересчитанный хеш события отличается; его подпись больше не охватывает измененное событие
Восстановление измененной записи и всех последующих хэшей Исходные подписи не проходят проверку; сохраненная контрольная точка на затронутой границе также не совпадает
Удалите конец фразы, но сохраните оставшийся префикс без изменений Ранее сохраненная контрольная точка, расположенная за пределами указанного префикса, указывает на то, что экспортный файл имеет недостаточный объем
Повторная подпись замещающего журнала с использованием другого ключа Отпечаток ключа, прошедшего отдельную проверку на доверие, отклоняет попытку подмены идентификационных данных

Изменение значения сохраненного поля приводит к изменению его дайджеста; повторное вычисление хэшей не восстанавливает исходные подписи.

Попробуйте применить эту логику к записи № 2: замените Meet at 11:00 на Meet at 12:00 в сохраненном событии. Пересчитанный хеш больше не совпадает. Пересчет последующей цепочки позволяет восстановить её звенья, но не может заставить исходные подписи покрывать новые дайджесты. Напротив, зафиксированное редактирование в Telegram становится новой записью в журнале.

Схема статических изменений

Наличие одних лишь хеш-ссылок не препятствует пересчёту цепочки замен. Доверие основывается на проверке подписей с помощью независимого доверенного ключа и сравнении с эталонными данными, хранящимися за пределами коллектора.

Что добавляет предыдущий контрольный пункт#

Сохраните счетчик 3 и заголовок h3; последующий экспорт 4 записей проверяется в позиции 3.

Контрольная точка остаётся неизменной, в то время как журнал пополняется. Если в контрольной точке указано: «3 записи, заголовок h3», экспорт из четырёх записей может пройти проверку благодаря совпадению с h3 на третьей позиции. Его новейший заголовок — h4, который, как и ожидается, будет отличаться. Экспорт, содержащий только две записи, не пройдёт проверку.

Схема статических контрольных точек

После проверки подписи контрольной точки необходимо:

Nexport ≥ Ncheckpoint   and   hexport[Ncheckpoint] = Hcheckpoint

Экспорт данных может выходить за пределы контрольной точки. Он должен совпадать на сохраненной границе. Настоящий верификатор также проверяет последовательность каждого события, предыдущую ссылку, хеш и подпись. Сравнение только конечной сохраненной заголовки приведёт к пропуску измененной внутренней записи, хеш которой не был обновлён.

Где находится «Witness»#

Блок-схемаСборщик / сессия учетной записи / ключ A → Конечная точка контрольной точки, доступная только для чтения; Witness / закреплённый ключ сборщика / собственный ключ B → Отдельный подписанный журнал свидетельств; Witness / закреплённый ключ сборщика / собственный ключ B → Конечная точка контрольной точки, доступная только для чтения (Запросить проверку); Конечная точка контрольной точки, доступная только для чтения → Witness / закреплённый ключ сборщика / собственный ключ B (Подписанный ответ); Witness / закреплённый ключ сборщика / собственный ключ B → Канал с подписанными сообщениями TGW1 (API бота / собственный токен)Хост AХост BСборщик / сессия учетнойзаписи / ключ AКонечная точка контрольнойточки, доступная толькодля чтенияWitness / закреплённыйключ сборщика /собственный ключ BОтдельный подписанныйжурнал свидетельствКанал с подписаннымисообщениями TGW1Запросить проверкуПодписанный ответAPI бота / собственный токен
Схема в текстовом формате
  1. Сборщик / сессия учетной записи / ключ A → Конечная точка контрольной точки, доступная только для чтения
  2. Witness / закреплённый ключ сборщика / собственный ключ B → Отдельный подписанный журнал свидетельств
  3. Witness / закреплённый ключ сборщика / собственный ключ B → Конечная точка контрольной точки, доступная только для чтения (Запросить проверку)
  4. Конечная точка контрольной точки, доступная только для чтения → Witness / закреплённый ключ сборщика / собственный ключ B (Подписанный ответ)
  5. Witness / закреплённый ключ сборщика / собственный ключ B → Канал с подписанными сообщениями TGW1 (API бота / собственный токен)

Свидетель фиксирует откат записей, наличие другого заголовка при том же счётчике, смену ключей, недопустимые ответы и отсутствующие ответы. Увеличение значения счётчика само по себе не доказывает, что все более ранние записи остались неизменными; сравните экспорт с сохраненными контрольными точками. Размещение свидетеля на другом хосте позволяет избежать последствий сбоев на хосте сборщика данных; наличие отдельного оператора обеспечивает дополнительную независимость.

Свидетель подтверждает состояние журнала, сообщаемое сборщиком данных. Он не осуществляет независимого мониторинга всех сообщений Telegram. См. инструкцию по настройке свидетеля.

Проверка доставки с учётом известных действий#

Используйте контрольную группу, отдельные учетные записи для сбора данных и новый маркер. Направляйте, редактируйте и удаляйте сообщения целенаправленно, проверяя запись на каждом этапе. Определите ожидаемые действия и предельный срок перед проверкой результатов.

R = |observed∩expected| / |expected|      Δ t = treceipt - taction

Учитываются только ожидаемые действия; дубликаты подтверждений не увеличивают числитель. Знаменатель должен быть не равен нулю. Отсутствующее подтверждение не имеет измеренной задержки. Укажите погрешность времени; используйте собственное контролируемое время действия удаления, поскольку Telegram не предоставляет точное время удаления. Результат, например, 5/6 (83,3 %), описывает тестовые действия, а не полноту всего трафика Telegram.

Выберите рабочий процесс#

Полный пример расследования прослеживает инцидент в канале, группе, боте и личном чате:

  1. Включите режим «Расследование всего аккаунта» и проведите инвентаризацию всех доступных чатов.
  2. Получайте моментальные снимки журнала, полную историю каждого чата и сохраненные вложения.
  3. Отражайте оперативные изменения и любые целенаправленные действия с панелями вместе с соответствующими подтверждениями.
  4. Отслеживайте цифровые идентификаторы отправителей, связи между ответами, повторяющиеся адресаты и хэши файлов посредством ссылок на записи и профилей пользователей.
  5. Восстановление хронологии переписки между чатами с указанием временных меток и явных пробелов.
  6. Сравнивайте рабочие пространства других учетных записей, сохраняя при этом их происхождение и ключи отдельно.
  7. Соберите и проверьте подписанные журналы, профили и экспортированные данные истории вместе с примечаниями по делу.

Руководство «/docs/cases/» на сайте содержит интерактивную карту дел и варианты решений для споров с ботами, удалённых сообщений и случаев смены имён участниками. Заметки по делам и межрабочих пространств анализ осуществляются внешними средствами; приложение не генерирует автоматически глобальный график расследования или объединенный архив дел.

Завершённая валидация и оставшиеся задачи · Экспорт и проверка · Начните с одной учетной записи