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

Сейчас почти весь 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-сертификатами.

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

Администраторы настраивают DNS “как получилось”, с ошибками и дефектами – указаны IP-адреса вместо хостнеймов при делегировании, указаны лишние NS, серверы имён не отвечают на запросы SOA и т.д., и т.п. Однако система как-то работает. Только вот попытка использовать эти настройки в более или менее строгом варианте, – например, для проведения проверки права управления доменом (DCV), – наталкивается на эти ошибки и проверка не срабатывает. Потому что есть случаи, когда игнорировать дефекты настройки DNS нельзя. Обнаружение этих “дефектов”, например, может свидетельствовать об идущей атаке.

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

Проблема эта, конечно, не только DNS касается.

В продолжение предыдущей записки. Два подхода к аутентификации сервисов и приложений – по отпечатку (значению) открытого ключа и по 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 (по сертификатам) – совершенно разные, нельзя их смешивать.

Пишут, что в браузере Firefox внедряют встроенный “сервис VPN”, который будет доступен “только для браузера”. То есть, строго говоря, это не VPN на уровне операционной системы, а именно наложенная сеть, предназначенная для клиентов-браузеров, поддержка которой в браузер и встроена. И такая сеть служит транспортом для доступа к веб-ресурсам конкретно браузером.

Развитие в этом направлении давно ожидалось: это логичный шаг, а сходную систему внедряет Google для Chrome. В целом, то, что веб, с точки зрения доступа, будет замыкаться внутри браузера, стало понятно ещё тогда, когда браузеры получили собственный доступ к DNS, минуя операционную систему – сейчас это встроенная в браузеры поддержка доступа к DNS-резолверам через DNS-over-HTTPS/DNS-over-TLS.

Доставка трафика через собственную наложенную сеть хорошо соответствует концепции “Интернет – это то, что показывается в браузере”. Конечно, веб – это лишь один из сервисов, работающих поверх Интернета, однако сейчас получается, что именно развитие технологий доступа к веб-сервисам продвигает создание сетей типа IP-over-IP.

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, конечно, будет сложнее.

Занятное совпадение. Недавно размещал на dxdt.ru фотографию двухфунтовой британской памятной монеты, посвящённой писателю Оруэллу. Монета вышла в этом году, в 2025. И вот, оказывается, на днях в Великобритании вполне себе официально заявили (англ., правительственный пресс-релиз), что собираются вводить там всеобщее “цифровое удостоверение личности” (Digital ID), в виде приложения на смартфоне, которое приложение будет обязательным, как минимум, для того, чтобы при найме подтвердить разрешение на работу (Right to Work, это и на граждан распространяется), а как максимум – чтобы в супермаркете купить продуктов.

Если так, то условный “смартфон” становится необходимым. Тут слово “смартфон” в кавычках потому, что ведь устройство не обязательно будет иметь именно форму смартфона – ведь нужно как-то решить проблему с теми, кто смартфоном не пользуется. Кто бы, как говорится, сомневался. Сюжеты на монеты так просто не попадают.

Кстати, в продолжение недавней заметки про то, что тип 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 – действительные числа, “просто с погрешностью” (“просто”, да). Соответственно, получается, что конкретный математический аппарат, служащий основой проектирования алгоритмов ПО, оперирует действительными числами, синусами и косинусами – здесь всё со всем пересекается, всё максимально гладкое, а поэтому выполняются нужные равенства и теоремы существования. Потом математический аппарат прямо переносят в программный код. После чего, в один не самый ожидаемый момент, вычисления ломаются и предположим, аппарат космический улетает совсем не туда, куда предписывала гладкая и непрерывная модель с синусами и дистрибутивностью.

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

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

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

Всё это не отменяет того, что нужно ожидать внедрения юридической значимости для указаний, выдаваемых неким LLM-ИИ – это одна из реальных “угроз ИИ”, про которые, впрочем, газеты тоже не оособенно распространяются.

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

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

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

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