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

Пишут (The Guardian, англ.), что в Штатах расследуют некие заявления о наличии у провайдера сервиса мессенджера WhatsApp возможности читать частные сообщения пользователей, несмотря на заявленную в протоколе криптографическую защиту “точка-точка” (E2E). В статье, кстати, прямо противопоставляют эту “архитектурную особенность” WhatsApp архитектуре мессенджера Telegram, который подобной “защиты” не предоставляет по умолчанию. Это сравнение, похоже, уже стало штампом в околотехнической журналистике. Но в статье интересен другой момент – там есть цитата эксперта, в которой говорится следующее:

Идея, что WhatsApp может выборочно и задним числом получать доступ к содержанию [зашифрованных в режиме “точка-точка”] индивидуальных чатов, представляет собой математическую невозможность. (Оригинал: “idea that WhatsApp can selectively and retroactively access the content of [end-to-end encrypted] individual chats is a mathematical impossibility”).

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

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

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

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

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

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

Кстати, о языках программирования из моей практики. В прошлом, 2025, году, как обычно, я довольно много использовал Go. Наверное, этот язык – на первом месте у меня, “по распространённости”.

Необычно много, – ну, по моим меркам и нынешним временам, – было C/C++. Но, в основном, это микроконтроллеры PIC и AVR. Хотя, одна старая утилита для x86, написанная на C, тоже попалась.

Заметный объём JavaScript – тут нечего добавить. Shell-скрипты – да, регулярно нужен Bash.

Как обычно, регулярно использовал Python, но, так сказать, ситуативно – лишь потому, что это входной язык Sage, системы компьютерной алгебры.

А вот ассемблеров за прошлый год попадалось меньше, чем обычно. И, опять же, почти всегда – для микроконтроллеров.

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

И иногда попадался Rust. Ну, как попадался: иногда приходится читать код, а кроме того, например, написал я на Rust микроскопический пример для статьи про сложение точек эллиптической кривой на “Хабр”.

Разнообразие, получается, не слишком велико.

В 2023 году я писал, что замена нормальных процессов разработки программного обеспечения на генерирование кода силами ИИ/LLM может привести к получению “транслятора тестовых примеров” вместо реализации шифра. Цитата:

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

“Кто бы мог подумать”, но уже в 2026 году в Cloudflare, – а это компания, которая раньше, вполне заслуженно, считалась технологическим лидером целого большого сегмента ИТ, – опубликовали в официальном блоге описание и код якобы специализированного Matrix-сервера, работающего на их, Cloudflare, коммерческой инфраструктуре (как сервис). С “постквантовой криптографией”, да.

Оказалось, что этот код сгенерирован ИИ/LLM, содержит грубейшие ошибки и, что главное, не реализует целый пласт необходимых функций. То есть, это не Matrix-сервер.

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

   // For now, store the seed as both public and private (placeholder) 
   // In production, use proper Ed25519 implementation 
   const publicKey = btoa(String.fromCharCode(...seed.slice(0, 32))); 
   const privateKey = btoa(String.fromCharCode(...seed)); 

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

   // Canonical JSON representation 
   const canonical = canonicalJson(obj); 
   const hash = await sha256(canonical); 
  
   // Placeholder signature - in production use Ed25519 
   const signature = hash;

Потому что это результат LLM. К тому же, очевидно, результат – не прошедший даже минимальной проверки (а зачем? это же замедляет процессы; компьютер с LLM – “не может ошибаться” и скоро уже будет писать код, “непонятный для человека, а поэтому – сверхэффективный”).

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

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

Нередко приходится слышать и читать, что в ECDSA значение “параметра k” должно вырабатываться криптографически стойким генератором (псевдо)случайных чисел, для каждой операции подписи. Например, так написано в английской “Википедии”, и практически то же самое написано в стандарте FIPS 186 (но обратите внимание, что в современном стандарте уже есть и другой вариант). Нельзя сказать, что это уж совсем неверно, но есть занятные тонкости с трактовкой слова “должно”.

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

Так, из требования секретности k, в частности, следует, что нельзя использовать предсказуемое значение, даже если оно предсказуемо “частично” (то есть, на каких-то интервалах). Потому что иначе атакующий может определить k на основе внешней информации (предсказать). Отсюда же выводится и то, что нельзя использовать одно и то же значение k для разных сообщений и одного ключа, потому что у атакующего появляется информация о соотношении между значениями k – они будут равны (это самая известная практическая атака на реализацию ECDSA). И так далее.

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

Соответственно, требование, чтобы k являлось выдачей генератора (псевдо)случайных чисел – не является необходимостью: есть варианты детерминированного алгоритма ECDSA, где секретное k генерируется детерминированным образом (то есть, заведомо не случайно на стороне реализации алгоритма), что даёт одно и то же значение подписи для одинаковых сообщений в разных итерациях. Для “классической” ECDSA это не так – там значения подписи будут разные, что нередко создаёт дополнительные сложности при отладке.

Кстати, всё это непосредственно применимо и к современной ГОСТ-подписи: там есть такой же “параметр k”, точно так же влияющий на выдачу криптосистемы подписи и на стойкость реализации.

Сurl отказывается от программы вознаграждений за найденные уязвимости (bug bounty), которая несколько лет работала на базе Hackerone. Основная причина: затапливание “ИИ-помоями” (ложными и абсурдными сообщениями об уязвимостях, сгенерированными ИИ/LLM), которые отнимают очень много ресурсов разработчиков, но не несут с собой ничего полезного для проекта.

Превращения слов. Систему Kubernetes на русском ИТ-жаргоне очень часто называют “Куб” или “Кубик”. Что, конечно, довольно забавно, потому что это дважды трансформированное из греческого через английский “фонетическое сокращение”. Дело в том, что исходное древнегреческое κυβερνήτης (“рулевой, кормчий, управляющий”) соответствует русскому “губернатор”. Так что должно быть не “куб” (которое, из-за “кубических мер”, много в каких жаргонах и арго фигурирует, но с другими значениями), а “губер”.

В DNS есть несколько штатных способов создать циклы, которые сделают обычный рекурсивный опрос невозможным. Самый привычный способ – использование субординатных NS. То есть, пусть зона example.com делегирована на два авторитативных NS – ns1.example.com, ns2.example.com. Оба имени находятся в исходной зоне example.com, откуда и название “субординатные”. Чтобы найти A-запись в зоне example.com – резолверу нужно опросить хотя бы один из авторитативных NS-ов, а чтобы опросить NS, нужно знать его IP-адрес (A- или AAAA-запись), а чтобы узнать IP-адрес – нужно опросить авторитативный NS зоны example.com, ну и так далее.

Если бы не glue-записи с IP-адресами, то разрешить такой цикл было бы невозможно. Glue-записи – это специальный способ предоставить резолверу IP-адреса узлов, которые, из-за циклов в адресации, невозможно найти обычным рекурсивным опросом. Эти записи передаются авторитативными серверами в специальной секции DNS-ответа и, в случае примера выше, сразу содержат IP-адреса для имён ns1.example.com, ns2.example.com. Без glue-записей практическая DNS работать не будет. И не только по причине наличия только что описанного элементарного цикла: есть случаи и посложнее.

Один из таких случаев – “кросс-делегирование”. Предположим, что зона example.net делегирована на ns1.example.com, ns2.example.com. Обратите внимание: из зоны .net – делегируется на имена в .com. При этом зона example.com – делегирована на ns1.example.net, ns2.example.net.

Теперь предположим, что резолвер ищет A-запись для example.com. Как резолвер мог бы действовать:

(0) для обнаружения нужной A-записи резолверу необходимо найти авторитативные серверы зоны example.com;

(1) на авторитативных серверах делегирующей зоны .com резолвер узнаёт, что NS для example.com – ns1.example.net, ns2.example.net;

(2) теперь резолвер должен определить A-записи для этих имён серверов (ns1.example.net, ns2.example.net);

(3) но для этого нужно найти авторитативные серверы зоны example.net;

(4) на серверах делегирующей зоны .net резолвер узнаёт, что имена этих серверов – ns1.example.com, ns2.example.com;

(5) теперь, чтобы узнать A-записи ns1.example.com, ns2.example.com, резолверу нужно определить авторитативные серверы зоны example.com, но это – шаг (1); получился цикл.

Естественно, настраивать так зоны, мягко говоря, не очень хорошо, даже несмотря на то, что данный цикл разрешается с использованием glue-записей. В случае использования glue-записей, их должна предоставлять каждая делегирующая зона, но в составе этих записей уже будут имена из другой зоны. То есть, в случае простого примера с субординатными NS для example.com – glue-записи содержат адреса серверов внутри example.com (ns1, ns2); в случае “кросс-делегирования” – адреса уже будут для имён в example.net.

Это далеко не все варианты создания циклов. Есть и ещё более сложное “петлевое” делегирование, и постоянно неверно используемая запись CNAME. Что касается CNAME, то это самая проблемная запись в DNS. CNAME предназначена для перезапуска процесса рекурсивного опроса. Вдумайтесь: в DNS изначально заложен сигнал, который, при штатном использовании, заставляет резолвер “начать заново”. Можно ли предложить лучшую основу для DoS? Вряд ли. Потому что если резолвер, отправив запрос про test.ru, получил CNAME с указанием на example.com, то он должен “забыть” исходное test.ru и начать опрос DNS для example.com. И так далее. CNAME можно указать для любого имени. Стоит ли говорить, что нетрудно построить цикл из нескольких CNAME? Нет, не стоит – это очевидно, а такой цикл может быть сколь угодно сложным.

Естественно, DNS-резолверы вынуждены отслеживать все эти особенности, чтобы не зависнуть.

Из серии “Кто бы сомневался!”: в Project Zero публикуют описание того, как, проэксплуатировав две уязвимости (CVE-2025-54957, CVE-2025-36934), им удалось выполнить на android-устройстве произвольный код с правами ядра ОС. Тут самое интересное не уязвимости, а то, что данную атаку на уровень 0-click (то есть, без участия пользователя) переводит наличие в смартфоне ИИ-агента, читающего входящие сообщения.

Вектор атаки требует, чтобы библиотека кодека прочитала специально подготовленный звуковой файл. Для этого нужно открыть и почитать вложение к входящему сообщению SMS/RCS. Раньше для этого пользователь должен был кликнуть на сообщение и попытаться открыть его. Но теперь за пользователя всё удачно делает ИИ-агент, встроенный в гугловый сервис и выполняющий транскрибирование всех голосовых сообщений.

Вот поэтому попадает в серию “Кто бы сомневался!”. Как говорится: эти ИИ-агенты – они и эксплоиты будут вместо пользователя на его устройстве запускать. Максимальная автоматизация.

(Описание на OpenNET.)

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

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

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

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

Рассмотрим практические особенности схемы с выделенной файлообменной машиной.

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

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

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

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

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

Почему-то часто считают, что SSH-доступ всегда эквивалентен локальному шелл-доступу к основной системе. Но это не так. Понятно, что, – по нынешним-то временам, – путь от локального аккаунта до суперпользователя не так долог, как хотелось бы (возможно, теоретически, это не так под чем-нибудь вроде хорошо настроенной FreeBSD, но речь про практическую ситуацию). Однако, никто ведь не сказал, что и SSH-сервер, и шелл, предназначенные исключительно для реализации обмена файлами, нельзя изолировать локально, выкинув всё лишнее, и не только под FreeBSD. Нет, вовсе не обязательно использовать тот же сервер и тот же шелл, которые нужны DevOps для управления. Напротив – подключаемся, заходим, а там изолированная директория и, вместо полноценного шелла, только урезанный набор из ls, mkdir, cat, (s)cp и mv (rename), предположим. То есть, для атакующего – опять дополнительные шаги и локальные хопы (loopback какой-нибудь использовать и пр.), а каждый хоп, не забывайте, тоже повышает шансы обнаружения вторжения.

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

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

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

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

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

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

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

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

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

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

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

Но, если возможность всё же есть, то что же это получается – это тогда никакой не “интеллект”? Получается так, да.

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

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

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

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

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

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

Сейчас тема развилась так хорошо, что на сторону провайдера ИИ/LLM-сервиса в онлайн-режиме передаётся исходный код программых продуктов, в том числе, внутренних корпоративных программных продуктов и экспериментальных версий. Да не просто код, а сведения о процессе подготовки этого кода. Заметьте, что провайдер обязательно использует этот новый код для “обучения” своих систем. А это прямо означает, что этот же код может быть передан другим пользователям сервиса. То есть, не просто провайдер получит код (тут можно вспомнить “социальную сеть” Github и пр.), но провайдер передаст этот код другим. (Тут вовсе не нужно вспоминать “копирайт” и прочие “бумажные соглашения”: как показала практика, поставщики ИИ/LLM на это внимания не обращают, списывая всё на добросовестное использование “в обучении” LLM.)

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