dxdt.ru: занимательный интернет-журнал

Кстати, что касается программ-мессенджеров. Естественно, тут вообще практическая часть задачи сводится к доверию конкретному приложению, которое, – в теории, – реализует “некоторую криптографию”. Более или менее игнорировать техническую часть, заключающуюся в доверии приложению, позволяет только хорошая подготовка и настоящий одноразовый “шифр-блокнот”: то есть, буквально, когда используется секретная книжечка с числами – это даёт абсолютную стойкость, но с большими оговорками. Во-первых, такие книжечки непросто распределять по участникам с сохранением нужной секретности, пусть металлический контейнер тут и получше новомодной квантовой криптографии; во-вторых, использование подобной ручной схемы всегда сопряжено с ошибками, которые легко перечёркивают слово “абсолютная” в характеристике стойкости; в-третьих – тут оказывается немало метаинформации, начиная с самой книжечки, как объекта. В общем – фантастика какая-то. Поэтому возвращаемся к приложениям.

Приложение может вообще не удалять локальные копии сообщений, даже если пользователь их, как бы, удалил. Приложение может вместе с зашифрованным сообщением отправлять копию в открытом виде, но через защищённый канал “клиент-сервер” в центральном мессенджере, так что обычный анализ трафика, проводимый интересующимся исследователем, ничего подозрительного не покажет. Приложение может генерировать одни ключи, а использовать – другие. А может и – просто генерировать нестойкие ключи, которые будут выглядеть как стойкие. Кстати, что касается симметричных криптографических ключей в мессенджерах, тот тут, почему-то, продолжают говорить, что “они есть только на клиентах”, при этом подразумевая согласование по открытому каналу. Так сейчас не бывает. Согласование секретных симметричных ключей через открытый канал, при помощи, например, алгоритма Диффи-Хеллмана, вовсе и не означает, что “ключи есть только на клиенте” – это “маркетинговый трюк”, я как-то писал об этом подробно. А вариант, в котором симметричные ключи действительно есть “только на клиентах”, это когда сами клиенты эти ключи не только генерируют, но и обмениваются ими по отдельному защищённому каналу: для оценки практической пригодности – см., опять же, первый абзац про книжечку-блокнот.

Проблема тут ещё и в том, что даже проверка совпадения результатов обмена ключами тоже проводится приложением, так что пользователь вынужден ему опять доверять. Заметьте, что ключи, даже если они были согласованы и проверены в результате корректной сессии обмена, могут быть прозрачно заменены уже на следующем шаге, в ходе обмена сообщениями, и речь тут вовсе не про необходимую ротацию ключей в современных сложных протоколах, предназначенных для защиты в режиме “точка-точка” (E2E), – ключи могут быть заменены на известные третьей стороне, а приложение забудет об этом сообщить. Впрочем, понятно, что всё это вообще не применимо, если на сервере сообщения передаются в открытом виде.

Адрес записки: https://dxdt.ru/2024/08/29/13783/