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

Пишут про метод, позволяющий обнаружить характер сообщений, которыми обмениваются пользователи с LLM через интерфейсы, использующие TLS. Там нет никакой уязвимости TLS, а речь идёт про анализ метаинформации о соединении: свойства потока TLS-пакетов, выдаваемых интерфейсом LLM, коррелируют с потоком токенов, генерируемых моделью; соответственно, зная примерные характеристики потоков токенов, выдаваемых по “чувствительным темам”, можно попытаться обнаружить факт обсуждения таких тем по TLS-трафику. Это давно известная особенность TLS-соединений. Работает не только для LLM, но и для прочих веб-интерфейсов приложений.

Процитирую фрагмент по этой теме из моего технического описания TLS:

Прослушивающая сторона может определить длину передаваемых TLS-записей, штатная работа протокола (до версии 1.3) не подразумевает каких-то эффективных средств маскировки длины сообщений, если они содержат достаточное количество байтов (маскировать длину данных необходимо дополнительно). Например, если пользователь загружал через веб-форму файл существенного объёма, то количество переданных байтов, очевидно, будет отличаться от сценария, когда пользователь просто закрыл веб-форму. Анализ длины переданных записей, порядка их следования, и сопоставление результата с особенностями веб-интерфейса, нередко позволяет точно определить, какие именно действия совершил пользователь.

Сейчас почти весь TLS-трафик в вебе, защищённый криптосистемами с постквантовой стойкостью, использует для согласования симметричных ключей гибридную криптосистему X25519MLKEM (X25519+ML-KEM). Что здесь означает термин “гибридная”? А означает он, что объединяются секреты, полученные в результате работы двух криптосистем: ML-KEM и X25519. Возможны сочетания ML-KEM с привычными вариантами ECDH – логика их устройства такая же, как и в случае X25519, поэтому дальше, в качестве примера, используется только X25519.

Итак, X25519MLKEM это не какая-то особенная криптосистема, в которой “объединяются X25519 и ML-KEM”, а всего лишь указание на параллельное использование пары криптосистем, где объединяются не криптосистемы, а их вывод – общие секреты сторон. Причём, даже это объединение выполняется самым простым способом: байты, выведенные ML-KEM, дописываются к байтам, выведенным X25519. Желаемую постквантовую стойкость обеспечивает часть ML-KEM. Минимальное практическая взаимосвязь реализаций двух криптосистем тут возможна разве что на уровне генератора (псевдо)случайных чисел и хеш-фунций (но при этом ML-KEM использует SHA-3/SHAKE256).

Таким образом, в сильно гипотетическом случае появления квантового компьютера, пригодного для криптоанализа, стойкость подобных гибридных ключей всего лишь упадёт в два раза, если считать по битовой разрядности: квантово-компьютерный атакующий сможет вычислить секрет X25519.

Гибридный подход требует выполнения операций двух криптосистем в каждом сеансе получения симметричных секретных кючей. То есть, буквально, нужно выполнить все шаги X25519 (сформировать и отправить открытый ключ, получить открытый ключ второй стороны, вычислить общий секрет) и все шаги ML-KEM (сформировать открытый ключ, сформировать шифротекст на другой стороне соединения, передать/прочитать шифротекст и вычислить секрет на принимающей стороне). Несмотря на то, что конкретно TLS позволяет переиспользовать выдачу X25519 в одной сессии, всё равно гибридизация выглядит перегруженной.

Зачем же тогда нужен гибрид? Базовая причина довольно простая: подстраховать ML-KEM на тот случай, если данная криптосистема окажется очень уязвимой для классических атак. Проще говоря, сломают именно алгоритм ML-KEM. Вообще, идея внедрения постквантовой криптографии довольно старая (это может показаться контринтуитивным, но криптосистемы с постквантовой стойкостью появились даже раньше, чем был предложен квантовый алгоритм Шора для взлома других криптосистем). Эксперименты с практическим внедрением новых криптосистем в TLS тоже проводились раньше, до появления стандарта на ту же криптосистему ML-KEM.

Например, в 2019 году Cloudflare совместно с Google Chrome испытывали сочетание SIKE и X25519 (эксперимент CECPQ2b), где постквантовую стойкость относили на счёт криптосистемы SIKE. Однако использованная версия SIKE оказалась недостаточно стойкой к классическим атакам. Так что, не будь в составе того эксперимента X25519, которая пока сохраняет свою стойкость, все TLS-сессии, установленные в рамках эксперимента с SIKE, были бы сейчас скомпрометированы постфактум (если, конечно, их кто-то записал). Квантовый компьютер для этого не потребовался бы. Такая же ситуация возможна и для ML-KEM (пусть ML-KEM и использует другой, относительно SIKE, математический аппарат).

Однако соответствующий стандарт NIST на ML-KEM никакой гибридизации с “классической” криптосистемой не требует: почему-то считается, что данная криптосистема имеет достаточную “классическую стойкость”. Тут необходимо отметить, что никто, естественно, не гарантирует стойкость ML-KEM. Оценка стойкости криптосистем в целом, и асимметричных криптосистем в частности, представляет собой дисциплину, наполненную эвристикой, предположениями и “допусками” при моделировании. С сугубо теоретической точки зрения не известно, возможны ли в принципе стойкие криптосистемы кроме единственной абсолютно стойкой (шифр Вернама), в которой длина секретного ключа равна длине сообщения. Так что для практических криптосистем лишь предлагаются оценки стойкости, взятые в некоторой модели вычислительных ресурсов. А потом появляются всё новые и новые атаки, понижающие предложенные оценки.

Конечно, именно поэтому никто не может гарантировать, что завтра не будет полностью взломана и X25519 – классическая часть гибрида с ML-KEM. Но, всё же, ML-KEM и более новая, и использует другой математический аппарат. А X25519 уже успешно и массово работает десятилетиями, а эффективных атак пока выявлено не было. Как бы там ни было, но один факт не вызывает сомнений: две независимых криптосистемы, – обычно, – лучше, чем одна.

Кроме теоретических аспектов, важны и практические: для той же ML-KEM требуется новая реализация, в которой много других алгоритмов, по сравнению с X25519 (или каким-то ещё вариантом ECDH). Новая реализация – это всегда новые дефекты и уязвимости именно в реализации, без учёта самого математического алгоритма. То есть, если использовать только ML-KEM – практически гарантированы новые критические ошибки, которых уже нет во второй части гибрида – в X25519. Более того, части ошибок реализации в X25519 просто и не может быть, потому что там другая математика.

Считается, что ML-KEM защищает от криптоанализа на гипотетическом квантовом компьютере. Очевидно, если бы подходящий квантовый компьютер появился, то использование гибридной пары с X25519 тут же потеряло бы смысл, так как эта криптосистема оказалась бы взломана. Чем не обоснование для отказа от гибрида? Но ведь этого квантового компьютера ещё нет и на горизонте! Так что обосновывать этим гипотетическим событием отказ от гибридных криптосистем на практике – несколько странно. Особенно, если учитывать, что никто не отменял классических атак на ML-KEM, и они пока что выглядят куда более реальными, чем квантовый компьютер для криптоанализа.

И тем не менее: стандарты – не требуют гибридов, а в IETF уже есть черновики RFC, описывающие “чистое” использование той же ML-KEM в TLS 1.3.

Cloudflare собираются вместе с Google тестировать новый формат TLS-сертификатов в браузере Chrome. Это сертификаты, в которых вместо значения подписи размещается доказательство принадлежности к дереву Меркла (дерево хешей), где соответствующий корень подписан удостоверяющим центром (УЦ). Это принципиально иная структура, по сравнению с действующей в TLS для веба сейчас. Подписи не будет в оконечном сертификате, но зато и проверять в типичном сценарии нужно меньшее количество подписей. Схема хорошо подходит для криптосистем с постквантовой стойкостью: в этих криптосистемах запись значения подписи часто требует много байтов, а использование дерева позволяет эти значения не передавать вместе с каждым сертификатом. При этом хеш-функции, в целом, считаются достаточно стойкими к гипотетическим атакам на квантовом компьютере. Стойкость доказательств, использующих дерево Меркла, основана на стойкости хеш-функций (помимо подписи, конечно).

То есть, если схему упростить, то УЦ выпускает сертификаты пачками, объединяет их в дерево Меркла и подписывает корень. Схема аналогична тому, как устроены логи Certificate Transparency. Сторона, проверяющая такие сертификаты, должна считать доверенным подходящий корень дерева: то, что значение конкретного сертификата сходится к нужному корню – проверяется путём вычисления значений хеш-функций от сертификата и от вершин, поддерживающих путь к корню; нужные для проверки значения хеш-функций как раз и передаются вместо подписи в сертификате. По ссылке выше есть картинки, объясняющие принцип.

Это пока что эксперимент. В роли тестового УЦ, выпускающего сертификаты “деревьями Меркла”, выступит Cloudflare. Но обещают, что это будет не полноценный УЦ, а только сервис, просто укладывающий “в дерево” уже выпущенные действующим доверенным УЦ сертификаты. Соответствие сертификатов разных типов станет проверять Google, прежде чем раздавать в браузеры соотвествующие “корни доверия”. Обратите внимание, что тут речь про корни в терминах схемы с деревьями Меркла: это совсем не то же самое, что корневые ключи УЦ – ключи УЦ остаются, в том числе, корневые, но они здесь используются для проверки подписей на корнях дерева, охватывающего некоторый набор сертификатов. В разрабатываемой схеме, вообще говоря, будут не просто корни, а некоторые опорные узлы, позволяющие дереву расти. Возможно, я напишу отдельную подробную записку про эту технологию, которая технология, кстати, полностью поменяет имеющуюся сейчас инфраструктуру УЦ для веба. Поменяет уже на техническом уровне. В общем, довольно интересное развитие истории с TLS-сертификатами.

В продолжение предыдущей записки. Два подхода к аутентификации сервисов и приложений – по отпечатку (значению) открытого ключа и по TLS-сертификатам. Сравним эти подходы с точки зрения того, на какое звено оказывается завязана аутентификация на практике. Пример первого подхода, непосредственно по ключам, – классическая конфигурация SSH (но не только, конечно, можно посмотреть на WireGuard и другие протоколы). Пример второго подхода – TLS с двухсторонней аутентификацией (клиента и сервера, mTLS).

Предположим, что у нас клиент (приложение) обращается к серверу. И приложение обнаруживает сервер по имени, с использованием DNS. Пока что будем считать, что и в первом, и во втором случае, системные и сетевые настройки – типовые, а вариант с TLS использует системный список хорошо известных доверенных УЦ (случай с собственным выделенным УЦ разобран отдельно). Рассмотрим разные ситуации в рамках задачи подмены сервера. То есть, задача атакующего – получить подключения клиентов на свой сервер так, чтобы клиенты ничего не заметили. Клиенты здесь – это приложения.

Что получается с вариантом TLS. Клиент находит IP-адрес сервера через DNS, а проверяет подписи в сертификатах. Ни то, ни другое – не привязаны к серверу. Поэтому, – “внезапно!” – решение оказывается полностью завязано на защиту авторитативных серверов зоны, в которой размещены имена серверов, и DNS-резолвера. Почему? Потому, что если атакующий может подставить IP-адрес своего сервера в ответ DNS, то клиент станет подключаться по TLS к подставному серверу. При этом клиент проверяет только валидность серверного сертификата, то есть, подпись на сертификате должна сходиться к доверенному ключу удостоверяющего центра (УЦ). Но при типовых настройках в этом списке больше сотни УЦ, а контроль над авторитативными серверами DNS (даже над одним) позволяет выпустить сертификат для нужного имени в одном из этих УЦ, например, в Let’s Encrypt. Естественно, речь о системе, которая находится в глобально доступной DNS. Но, скажем, Let’s Encrypt и так повсеместно используется для внутренних имён разных API и тому подобных штук: посмотрите в CT-логи, если хотите убедиться лично.

Тут нужно заметить, что получение контроля над локальным DNS-резолвером атакуемой системы не позволяет выпустить сертификат от внешнего УЦ (потому что УЦ использует другой DNS-резолвер), но всё равно позволяет перенаправить клиентов: в теории, при отсутствии на подставном сервере валидного и доверенного сертификата, клиент обнаружит подмену средствами TLS. (Впрочем, на практике валидацию на клиенте вообще нередко отключают – insecureSkipVerify и тому подобные вещи, – это, понятно, сводит тут защиту примерно к нулю; как и использование самоподписанного серверного сертификата.)

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

Промежуточный итог про TLS: даже при корректной реализации защита от подмены полностью завязана на стойкость DNS; защита никак не зависит от ключей на клиентах и серверах, а перехват DNS позволяет выпустить подменный сертификат от внешнего УЦ. То есть, даже если предполагается, что сертификат сервера должен быть от собственного, корпоративного УЦ, но в списке доверенных есть и ключи других УЦ, – а это часто так, – то сгодится сертификат от любого из этих УЦ. (Кстати, можно использовать не DNS, а локальную таблицу хостов. Это помогает частично, но тянет за собой другие риски.)

Теперь вариант с проверкой отпечатков ключей (SSH и прочие решения с key pinning). Значения допустимых ключей прямо задаются и на клиенте, и на сервере. Сейчас принято на клиенте сохранять серверный отпечаток при первом подключении. Но вообще известные отпечатки можно заранее настроить другими способами.

В этой схеме аутентификации, чтобы прозрачно подменить сервер – нужно утащить его секретный ключ. “Почувствуйте разницу”, потому что контроля над DNS недостаточно. Если DNS успешно переставлена, но на подменном сервере другой ключ, то клиент сразу же обнаружит подмену: значение открытого ключа не совпадает с ранее сохранённым отпечатком. Преимущество того же SSH тут в том, что уже штатные настройки клиента не позволяют подключиться просто так к серверу, который поменял ключ. (Да, на практике постоянно игнорируют этот момент, к сожалению.) Фундаментальное отличие от ситуации TLS – даже подмена DNS не позволяет прозрачно подменить сервер: нужен оригинальный секретный ключ. Просто взять открытый ключ и положить его на подставной сервер нельзя, потому что подставной сервер не сможет согласовать сеансовые ключи – чтобы подписать пакеты нужно знать серверный секретный ключ. В случае TLS, если есть возможность выпустить сертификат для нового ключа, то и знать исходный секретный ключ не обязательно.

Конечно, в схеме аутентификации по ключам подменный сервер может точно так же принимать любой клиентский ключ, без проверки, как и в случае клиентских TLS-сертификатов, но ситуация всё же лучше: третья сторона уже не может предоставить валидный способ аутентификации клиента. Напомню, что в случае с mTLS можно выпустить валидный клиентский сертификат без участия реального клиента, если есть доступ к УЦ. Но это, ообычно, другой УЦ – именно для клиентских сертификатов, скорее всего, внутренний (но не обязательно).

Промежуточный итог про отпечатки ключей и SSH: из-за того, что тут проверяется конкретный ключ, никакая внешняя подмена не поможет, поэтому схема перестаёт зависеть только от надёжности DNS.

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

Использование mTLS с собственным УЦ тоже помогает, но отчасти: если клиенты используют не типовой системный список доверенных ключей УЦ, а верят только в ключ конкретного, внутреннего УЦ, который предназначен строго для данной системы, ограничен в выборе хостов, а сертификаты выпускает по запросам администратора, то перенаправление DNS уже не сработает. Но и такая система оказывается защищена на уровне защиты упомянутого УЦ: то есть, ситуация оказывается даже несколько проще, и если есть сетевое перенаправление, то для успешной подмены сервера нужно получить контроль над скриптами внутреннего УЦ (а не DNS). Если вы подумали, что внутренний УЦ будет защищён лучше, чем DNS – то, как бы, это не обязательно так на практике.

Естественно, применение ACL на уровне сетей, на уровне виртуализации, сильно затрудняет подмену через DNS. Если доступ наружу открыт только в направлении некоторых “собственных сетей”, то перенаправить соединение на внешний узел просто так не получится. Но, во-первых, ACL могут настраиваться с использованием DNS; во-вторых, если ACL выстраиваются с точностью до IP-адреса (не IP-префикса), то зачем же тогда вообще прописывать хостнеймы? Как бы там ни было, но на описанные разные подходы к аутентификации – ACL не влияют.

Что-то опять довелось услышать сравнение аутентификации в SSH (по ключам) и двусторонней аутентификации в TLS (HTTPS) по сертификатам: мол, и там, и там – есть секретные ключи, которые нужно передавать для организации работы приложений, так что это одно и то же с точки зрения эксплуатации системы. Но это не так. Ситуации SSH и TLS тут различаются принципиально.

Посудите сами. Речь тут идёт о типовой схеме с SSH-ключами (в SSH тоже можно сделать “сертификаты”, но сейчас не об этом). Итак, в SSH имеем аутентификацию по отпечаткам ключей каждой стороны: сервер, фактически, проверяет отпечаток (то есть, значение – не важно) открытого ключа клиента; а клиент – отпечаток открытого ключа сервера. Стороны аутентифицируют каждая каждую напрямую, без помощи третьей доверенной стороны. Если ключ скомпрометирован, то его нужно непосредственно исключить по значению из списка доверенных. Например, удалить на сервере из authorized_keys.

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

Теперь TLS. Двусторонняя аутентификация: серверный и клиентский сертификаты. Тут обязательно участвует третья сторона: штатный способ аутентификации – проверка подписи на сертификатах ключей. Технически, можно сравнить отпечатки (key pinning и пр.), но это будет за рамками типовой схемы. Типовая же схема требует сравнения не отпечатка, а подписи, поставленной третьей стороной. Совсем другая история, по сравнению с SSH. Именно что от слова “совсем”. Тут уже нельзя “отключить ключ” клиента или сервера, просто удалив его из списка доверенных. А если нет способа внешней проверки статуса сертификата и способа отзыва сертификатов, то всякий действующий (по времени) сертификат с верной подписью удостоверяющего центра будет всегда принят стороной, проводящей проверку. Подпись известного удостоверяющего центра верна? Верна. Принимаем. Без вариантов.

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

В схеме SSH, чтобы подставить ключ на сервер – нужно прописать его значение в файл на сервере. В схеме с TLS-сертификатами – нужно подписать сертификат на стороне УЦ. На сервер, которому будет предъявлен валидный сертификат, даже не потребуется заходить.

Так что подходы к аутентификации в SSH и TLS (по сертификатам) – совершенно разные, нельзя их смешивать.

F-Droid – это независимый от Google Play репозиторий приложений для Android-устройств, с требованием открытого исходного кода и со своими правилами. Пишут, что проект F-Droid не сможет продолжать работу, если Google внедрит новую, строгую систему идентификации/аутентификации разработчиков.

Несмотря на излишний пафос сообщения, поспорить с базовыми положениями сложно – цитата:

We do not believe that developer registration is motivated by security. We believe it is about consolidating power and tightening control over a formerly open ecosystem. (Мы не считаем, что регистрация разработчиков мотивирована безопасностью. Мы считаем, что это касается сосредоточения полномочий и усиления контроля над экосистемой, ранее бывшей открытой.)

Я постоянно использую приложения из F-Droid. Они, обычно, лучше, чем схожие версии в Google Play, которые, в моём случае, вообще не работают. Без F-Droid, конечно, будет сложнее.

Кстати, в продолжение недавней заметки про то, что тип float – это не про числа, тем более, не про действительные числа. С точки зрения рекомендаций разработчику ПО.

Вообще, если получается, то никаких float и тому подобных инструментов лучше не использовать. Совсем. Тем более, в воплощении различных sin, cos и прочих. Заменять нужно таблицами целых (в смыcле int) значений и целочисленными, со строго фиксированной справа точкой, арифметическими операциями. Особенно, если речь о программировании систем управления и микроконтроллеров.

Если же не получается совсем отказаться, то есть эффективный способ правильно думать про float. Нужно переменные с типом данных float понимать как алгоритмы, и сравнение таких переменных интерпретировать как сравнение алгоритмов. Это помогает избежать многих ошибок (см. ниже).

Например, во float нет дистрибутивности. В алгоритмической интерпретации это означает, что выражения L := b*(c + d) и L := b*c + b*d – присваивают переменной L разные алгоритмы. И действительно, запись, в которой сперва вычисляется сумма (c + d), а потом результат умножается на b, это другой алгоритм, нежели вариант, когда сперва b умножается на d и b умножается на с, а потом вычисляется сумма результатов (обратите, кстати, внимание, что тут ещё и порядок играет важную роль: сначала b*c или сначала b*d? если с точки зерния параллельных вычислений эти операции могут быть выполнены “независимо” разными потоками, то с точки зрения компилятора, имеющего дело с вполне себе последовательной записью, всё может выглядеть сильно иначе – но это явно тема для другой записки).

Если не упускать этот алгоритмический момент из виду, то оступиться становится сложнее. Так, алгоритмическое восприятие float позволяет отбросить сомнения, что в двух описанных выше случаях из L можно достать разное битовое значение при одних и тех же входных переменных – алгоритмы-то там разные. Естественно, сравнивать алгоритмы сложно, но тут понятие об алгоритме – это лишь средство обобщения, мыслительный гаджет, но такой гаджет, который верно работает.

Лирическое отступление. Это раньше к компьютерными вычислениями подходили с нужной тщательностью и пониманием того, что такое преобразование погрешностей. Сейчас, оказывается, времена ИИ и LLM. Поэтому сказку сильно сократили. К сожалению, уже на практике полагают, что во float – действительные числа, “просто с погрешностью” (“просто”, да). Соответственно, получается, что конкретный математический аппарат, служащий основой проектирования алгоритмов ПО, оперирует действительными числами, синусами и косинусами – здесь всё со всем пересекается, всё максимально гладкое, а поэтому выполняются нужные равенства и теоремы существования. Потом математический аппарат прямо переносят в программный код. После чего, в один не самый ожидаемый момент, вычисления ломаются и предположим, аппарат космический улетает совсем не туда, куда предписывала гладкая и непрерывная модель с синусами и дистрибутивностью.

Мессенджер Signal внедряет платное централизованное хранение резервных копий сообщений на своих серверах. Занятно, что Signal позиционируется как “безопасный мессенджер”. Впрочем, вряд ли какое-то из этих новомодных приложений не позиционируется как “безопасное” или “самое безопасное”.

У Signal, что называется, и так “накрученный” протокол – в том смысле, что там большое количество логических слоёв, а это усложняет и понимание, и правильную реализацию. Теперь к этому прикручивают ещё и центральное копирование сообщений. Конечно, написано, что копии защищены “сквозным шифрованием” (расхожий маркетинговый термин, end-to-end), а восстановить их может только тот, кто знает специальный секретный ключ (предполагается, что это пользователь данного мессенджера). Конечно, это так только в том случае, если всё сработает штатно. Никакое зашифрование сообщений, как обратимая операция, не является аналогом уничтожения этих сообщений. Кроме того, нужно учитывать, что там заявлена подписочная модель оплаты, то есть, в дополнение к “сквозному шифрованию” должен быть какой-то “сквозной” публичный идентификатор – иначе платёжная система не сможет понять, кто за какую подписку заплатил (да, можно придумать перемешивание с привязкой по секретным ключам, но для этого нужно и оплату принимать совместимым способом, а это из области фантастики).

Раскрученные СМИ мессенджеры развиваются по схожим сценариям. Так что теперь в Signal, даже если пользователь уничтожил устройство с приложением, сообщения можно официально и штатно восстановить из центрального хранилища. Собственно, эта возможность и заявлена в качестве основной. Уничтожение устройства не является обязательным условием копирования сообщений из хранилища. А ключи – ключи утекают в результате ошибок или в результате “ошибок”.

Кстати, я в прошлом году писал про особенности хранения копий сообщений мессенджеров.

Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).

Эти сертификаты могут быть тестовыми – на такую мысль наводят использованные в них имена доменов. IP-адрес 1.1.1.1 кто-то мог ввести в качестве заглушки: по “старинной традиции” этот адрес многие воспринимают как “невозможный”. В любом случае – УЦ должен проверять право управления для всех имён и адресов, указываемых в сертификате, так что, если это тест, то он, к сожалению, не прошёл.

Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).

Дистрибутивность умножения относительно сложения означает, что a*(b + c) = a*b + a*c. В действительных числах, по определению, умножение дистрибутивно относительно сложения. Запишем это на Pyhton и посмотрим, что напечатает простая программа.

import math

q = 11*(math.sqrt(5) + math.sqrt(17))    # q = a*(b + c)
p = 11*math.sqrt(5) + 11*math.sqrt(17)   # p = a*b + a*c
print(p == q)                            # q == p => (q - p) == 0

q = 34*(math.sqrt(5) + math.sqrt(17))
p = 34*math.sqrt(5) + 34*math.sqrt(17)
print(p == q)                            # ???

Запускаем (Python 3.11.2) и смотрим:

True
False

В коде, в первом случае, написано:

p = 11*(√5 + √17),
q = 11*√5 + 11*√17.

Значения p, q сравниваются. Программа выводит True – значения равны. Что и следовало ожидать, если бы это были действительные числа: по определению, q и p – это одно и то же число.

Во втором случае написано всё то же самое, алгебраически, но другой множитель:

p = 34*(√5 + √17),
q = 34*√5 + 34*√17.

Удивительно, но результат сравнения p и q теперь False – числа не равны.

Да, конечно, причина в представлении типа float в компьютерной памяти: для 34 порядок округления сыграл свою роль – результаты разошлись в одном разряде. Обычно полагают, что этот пример лишь показывает ограничения битового представления float (и других типов). Но вообще-то основной вывод тут должен быть другим: для float не выполняется дистрибутивность умножения. То есть, операции с float – это операции с float, а не операции с числами, тем более, с действительными.

Компьютеры не работают с действительными числами. Потому что это невозможно. Да, натуральные, целые, рациональные – это подмножества действительных (с которыми подмножествами компьютеры тоже не работают, кстати). Но если вы случайным образом бросите точку на числовую прямую, то попадёте в иррациональное число. Запись этого числа в виде десятичной дроби – бесконечный процесс, который, впрочем, может быть формально определён – получится алгоритм вычисления конкретной записи числа (вспомним формулы для π, например).

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

Да, символьные вычисления, с успехом выполняемые компьютерами, позволяют работать с “иррациональностями”. Но символьные вычисления происходят в других математических структурах (в других кольцах, если хотите строго) и не работают с десятичной записью действительных чисел. То есть, если записывать √2 как символ “√2”, – в том смысле, что это обозначение числа, квадрат которого равен двум, – то тут проблем нет. Но совсем другое дело – преобразование десятичной записи.

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

Естественно, в хороших практических разработках это учитывается. Существенная часть практических алгоритмов в том же “машинном обучении” (Machine Learning – ML) как раз относятся к преобразованию подобных погрешностей. Корректная работа с погрешностями вообще очень важна при вычислительной обработке экспериментальных данных. Но почему-то всё равно приходится постоянно встречать утверждения, что “ML работает в действительных числах”.

Пишут (англ.), что Google собирается для всех разработчиков приложений под Android на google-сертифицированных устройствах потребовать регистрацию аккаунта и регистрацию ключей подписи. Регистрация, конечно, должна быть в корпорации Google. Иначе приложения невозможно будет устанавливать (механизм реализации запрета пока не описан, но это ведь детали). Разработчик должен регистрироваться и получать разрешение даже в том случае, если приложение не распространяется через Google Play, а публикуется каким-то сторонним сервисом. Фактически, всё идет к тому, что самостоятельно разработанное приложение нельзя будет без регистрации аккаунта разработчика установить на самостоятельно же приобретённое устройство (такое вот очередное подтверждение того, что “собственный” смартфон вовсе и не принадлежит, как система, купившему его пользователю).

Этого, конечно, следовало ожидать: эффективны именно ограничения по конкретным источникам исходного приложения, а не по “витринам-магазинам” (к которым относится и Google Play). “Витрины-магазины” можно обойти, как-то ещё раздавать код, другими способами. Но если в процессе подтверждения подпись от ключа разработчика проверяется всегда относительно некоторого центра доверия, встроенного в систему, то уже нет разницы, откуда взят сам код приложения.

Сверять цепочки подписей с “регистрацией”, конечно, будет вовсе не пользователь устройства, а центральный системный сервис. А отключение разработчиков от этого сервиса возможно, в том числе, по результатам очередных “широких санкций”: например, сервис ранней регистрации, который предлагает Google для этой программы, похоже, с российских IP-адресов уже сразу недоступен.

В статье Ars Technica (по ссылке выше) пишут, что Google, якобы, не планирует проверять само приложение (как в случае с Google Play). Но это вряд ли, что оно так будет. По крайней мере, в сопроводительных документах Google написано, что для бесплатных аккаунтов введут ограничения и по количеству приложений, и по количеству установок. Дело в том, что, технически, цифровой подписью всегда подписывается конкретная сборка (нельзя подписать произвольный идентификатор, который автоматически привяжется ко всем возможным вариантам – такого не предусмотрено). Поэтому и провайдер системного сервиса проверки вполне может регистрировать в центральном репозитории тоже только конкретные сборки, по отпечатку. А это эквивалентно проверке кода приложения: по результатам – можно отключить и аккаунт, и сами приложения удалить с пользовательских устройств.