Целостность сообщений: может ли сервер изменить зашифрованный чат?

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

Главное

• Аутентифицированное шифрование выявляет изменение шифротекста, но не обязательно сохраняет историю правок и удалений.
• Согласно техническим документам Livara, AES-256-GCM защищает личные сообщения тегом аутентификации; изменённый пакет не должен расшифровываться как действительный.
• Разрешённая правка должна быть новым событием со сквозным шифрованием, а не скрытой перезаписью прежнего пакета сервером.
• Номера безопасности помогают проверить ключ собеседника, а не его честность или юридическую силу снимка экрана.
• В чувствительных спорах храните исходный файл, временные отметки, статус редактирования и независимые свидетельства также вне ветки переписки.

Что именно означает целостность сообщений?

Целостность сообщения означает, что получатель может обнаружить несанкционированное изменение зашифрованных данных. Конфиденциальность спрашивает: «Кто может прочитать текст?»; целостность: «Пришли ли те же данные, которые зашифровал отправитель?». Объяснение сквозного шифрования и его границ подробнее раскрывает эту разницу.

Это концептуальная иллюстрация с демонстрационными подписями, а не реальный интерфейс Livara и не результат теста отклонения изменённого сообщения.

По техническим документам Livara прямые сообщения шифруются сквозным образом с LVR1, а совместимые закрытые группы — с LGS1. Согласно странице безопасности Livara, старая несовместимая группа явно остаётся вне E2EE, а новая не создаётся с отметкой шифрования до готовности всех участников. Проверяйте состояние конкретной беседы. Документы указывают, что LVR1 использует ECDH P-256 и ML-KEM-768 для выработки ключа сообщения. Стандартизация компонента не означает независимого одобрения всей комбинации или продукта. Затем Livara использует AES-256-GCM для защиты содержимого.

По документации продукта эта защита охватывает текст, правки и вложения личных бесед. Но каналы Livara не имеют сквозного шифрования: сервер намеренно может читать их содержимое, в том числе для удаления злоупотреблений. Членство в группах также контролирует сервер. Безопасность звонков и режим записи следует оценивать отдельно от текстовых сообщений.

Обнаружение изменения шифротекста и AES-256-GCM в мессенджере

Помимо шифрования содержимого AES-GCM создаёт тег аутентификации. Если изменятся шифротекст или аутентифицируемые данные, проверка тега должна завершиться неудачей. NIST SP 800-38D определяет режим GCM и предупреждает, что повторное использование nonce с одним ключом может серьёзно ослабить безопасность.

Согласно технической спецификации Livara личные сообщения используют AES-256-GCM. Если сервер изменит часть защищённого пакета, без ключа сообщения он не сможет создать новый тег; поэтому получатель не должен принять пакет как неповреждённый. Краткий ответ на вопрос «Может ли сервер изменить сообщение?»: сервер может удалить, удержать, заблокировать или задержать данные, но не должен иметь возможности выдать изменённое содержимое за действительное.

Гарантия не безгранична. Криптография не нейтрализует вредоносное ПО на устройстве, доступ злоумышленника к открытому экрану или разрешённую правку пользователя. Целостность содержимого также не обязательно скрывает метаданные. Руководство по метаданным мессенджеров и тому, что они раскрывают, объясняет эту границу.

Может ли сервер изменить сообщение, или редактирование — другое?

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

Согласно документации Livara правки прямого чата защищает LVR1, а совместимой закрытой группы — LGS1. Оценивая интерфейс, проверьте, показывает ли приложение статус «изменено»; однако криптография сама по себе не хранит предыдущую версию вечно на всех устройствах.

«Удалить у всех» — тоже запрос на удаление содержимого, а не доказательство уничтожения всех копий. Получатель мог увидеть сообщение, прочитать уведомление, сохранить файл или сделать снимок экрана. Исчезающие сообщения сокращают срок хранения, но не гарантируют удаления всех копий.

Что доказывает аутентификация сообщения чата?

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

В технических документах Livara номера безопасности представлены как способ обнаружить смену ключа. Два человека могут сравнить отпечатки ключей по независимому каналу; руководство по проверке чата с номерами безопасности описывает практические шаги. Это снижает риск замены ключа контакта ключом злоумышленника, но не делает заражённое устройство безопасным.

Аутентификация аккаунта — отдельный вопрос. Любой механизм входа, каким бы сильным он ни был, не заменяет целостность сообщений, проверку ключа контакта или безопасность устройства.

Целостность содержимого — не порядок и свежесть сообщений

У старого пакета может быть действительный тег аутентификации. Чтобы предотвратить повторное принятие, нужны дизайн протокола, счётчики, идентификатор сеанса и сохранение состояния получателем; AES-GCM сам по себе не является журналом порядка всей беседы. Это различие важно при оценке повторного воспроизведения, задержанных сообщений и синхронизации нескольких устройств.

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

Если текст или статус сообщения неожиданны

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

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

Как оценивать заявление о целостности мессенджера?

Не ограничивайтесь словом «зашифровано». Спросите:

• Какие беседы и файлы шифруются сквозным образом?
• Какой алгоритм AEAD использует сервис?
• Как регистрируются и отображаются правки и удаления?
• Как пользователь обнаруживает смену ключа контакта?
• Какие метаданные, содержимое или членство контролирует сервер?
• Дают ли звонки те же гарантии, что сообщения?
• Проходил ли протокол независимый аудит?

Livara публикует спецификации и инструменты для проверки некоторых своих заявлений, а пользователи Android могут сравнить контрольную сумму APK с SHA-256 в Proof Lab для офлайн-проверки приложения. Однако эта статья не предоставляет доказательства независимого аудита текущей версии. Публикация спецификаций и тестовых векторов помогает проверке, но не заменяет независимый аудит.

Для личных бесед основное заявление Livara ограничено и ясно: AES-256-GCM должен выявлять изменение пакета, а правки тоже должны шифроваться. Это не означает неизменяемого журнала, гарантированного удаления всех копий или автоматического юридического доказательства.

Частые вопросы

Может ли администратор сервера изменить текст зашифрованного сообщения?

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

Доказывает ли отметка «изменено», какой была предыдущая версия?

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

Гарантирует ли номер безопасности подлинность всех сообщений?

Нет. Он помогает проверить принадлежность ключа контакту и обнаружить его смену. Проверка не говорит, кто держал устройство при отправке, правдиво ли сообщение и нет ли на устройстве вредоносного ПО.

Удаляет ли «удалить у всех» сообщение отовсюду?

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