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

Хорошо известный удостоверяющий центр SSL.com выпускал TLS-сертификаты для доменов без проверки права управления. Как пишут, статус “подтверждённого имени” получал всякий домен, на произвольный почтовый адрес в котором пользователь смог получить код подтверждения для любого другого домена. То есть, можно было разместить заказ на TLS-сертификат для example.com, выбрать способ подтверждения с отправкой кода по адресу email, указанному в TXT-записи (и такое бывает), – например, akhmet@test.ru, – подтвердить получение кода, и доменное имя из состава адреса, – то есть, test.ru, – тоже получало статус прошедшего проверку права управления.

Очередное подтверждение того, что проверка права управления (DCV) должна проводиться перед выпуском каждого сертификата, для всех имён, указываемых позже в сертификате, и только для этих имён, но строго после получения соответствующего заказа (и процесс подтверждения должен быть привязан к конкретному заказу и к конкретному ключу из заказа). И, конечно, никаких проверок по email для TLS-сертификатов.

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

На днях опубликовал на “Хабре” небольшую статью про парадокс Ньюкома в применении к ИИ, как к программе. Так как статья небольшая, туда много что не вошло – см. ниже. (Но зато есть расшифровка диалога с ChatGPT по теме.)

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

Помимо прочего, парадокс Ньюкома прямо связан с интерпретациями квантовой механики – например, скажем, что Предсказатель использует машинерию, действующую в “аксиоматике” Дирака-Фон Неймана, то есть, вся онтология – только про результаты измерений. Но и если посмотреть на ситуацию с точки зрения исследования программ, то тут тоже возникают разные хитрости: если говорить строго, то не каждое сочетание программы и набора данных вообще “разрешимо” (см. десятую проблему Гильберта, проблему останова, теорему Райса и пр.) – получается теоретический сюрприз, пусть к конкретной практической ситуации он и не подходит. Но как быть, если моделирование программы ИИ, с целью предсказания выбора, проводит тоже ИИ – другая программа? То есть, вопрос о сущности Предсказателя получает некоторые новые грани.

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

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

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

Беспроводной телефон, использующий свет (солнечный) в качестве носителя сигнала, а нехитрую систему зеркал – в качестве модулирующей схемы. Из 1880 года, тоже от Белла. См. иллюстрацию.

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

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

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

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

Регистрацию домена dxdt.ru продлили на очередной год, пока что без всяких нововведений (кроме, разве что, возросшей в несколько раз стоимости у регистратора). Это я пишу в продолжение прошлогоднего сообщения о том, что, возможно, не получится продлевать. Посмотрим, как будет дальше.

P.S. У меня есть страница статуса под резервным адресом dxdt.root-key.net и несколько дополнительных доменов для имени dxdt в .su, .pw, .blog. Но вот куда и как переносить сайт, если переносить – я пока не придумал.

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

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

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

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

Опубликовал на “Хабре” небольшой разбор того, какую структуру имеют TLS-сертификаты, на примере “шестидневного” сертификата от Let’s Encrypt – какие хитрости есть в формате серийного номера, что будет с параметрами проверки статуса сертификата, как выглядят SCT-метки и пр.

Комапния “Яндекс” пишет, что “поиск Яндекса” научился объяснять “решение математических задач из старшей школы”. Конечно, при помощи нейросетей. Цитата:

Например, он [“Поиск”] может рассказать ход решения показательных и несложных тригонометрических уравнений, а также найти предел функции.
[…]
Яндекс обучил её [нейросеть] на одном миллионе примеров заданий для старшеклассников. Это позволило добиться точности ответов в решении задач в 90% случаев.

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

Для условий задач, составленных с ненамеренными ошибками – часто можно точно обнаружить ошибку, тоже системой компьютерной алгебры (но, понятно, не всегда: если условие испортить специально, то можно построить неразрешимый для компьютера случай). И тем не менее, там все символьные операции алгоритмизируются точно, пусть и не самым тривиальным методом. Так что не требуется угадывание описания процесса поиска ответа при помощи синонимайзера, который не так давно утверждал, что “число делится на 2 и на 11, а значит, делится и на 3”. Да ещё и с какой-то точностью ответов – “в 90% случаев”. Конечно, можно сказать, что 10% случаев – это и есть некорректно составленные задачи, но это будет выдумка, потому что тогда система должна была бы сказать, что задача некорректная, а не выводить неверное решение.

Можно ли “смешать” TLS-сертификаты для IP-адресов и для хостнеймов? Например, если говорить о TLS для HTTPS, то тут используются и адреса, и имена: поиск сайта, обычно, происходит по имени хоста (по доменному имени), но само соединение устанавливается по IP-адресу. Соответственно, TLS-клиент, – пусть это будет браузер, – на момент отправки первого TLS-сообщения серверу знает доменное имя и IP-адрес, который сам браузер поставил в соответствие этому имени (в процессе обнаружения адреса использовалась DNS, это понятно). Обычно, чтобы признать сертификат валидным, браузер ожидает, что в TLS-сертификате указано имя, соответствующее ожидаемому имени хоста – это может быть одно из нескольких имён в сертификате, может быть результат “раскрытия” wildcard-имени (“со звёздочкой”).

Технически, в TLS-сертификате, вместе с именами хостов, можно указать и IP-адреса, форматом допускается. За примерами не нужно далеко ходить – сертификат на веб-сервере dns.google содержит и DNS-имена, и IP-адреса:

X509v3 Subject Alternative Name: 
 DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com,
 DNS:8888.google, DNS:dns64.dns.google,
 IP Address:8.8.8.8, IP Address:8.8.4.4,
 IP Address:2001:4860:4860:0:0:0:0:8888,
 IP Address:2001:4860:4860:0:0:0:0:8844,
 IP Address:2001:4860:4860:0:0:0:0:6464,
 IP Address:2001:4860:4860:0:0:0:0:64

При этом dns.google показывает на те же IP-адреса, которые перечислены в сертификате. Это, конечно, не означает, что IP-адреса из сертификата должны быть связаны с именами в том же сертификате через DNS – просто, сертификат будет валиден и для любого из указанных IP-адресов отдельно (при совпадении подписей, конечно).

Однако в теории тот же браузер может потребовать, чтобы в сертификате и имя хоста совпадало, и IP-адрес, по которому установлено TCP-подключение. Двойная проверка.

Чем такая схема, если бы её реализовать, грозит? С одной стороны, схема неожиданным образом защищает от использования секретного ключа другим сервером, если таковой сервер использует другой IP-адрес. Подключение к подставному серверу можно реализовать подменой DNS, так что имя – совпадёт. Но не IP-адрес. Может ли атакующий, вооружённый секретным серверным ключом, соответствующим ключу в сертификате, подменить и IP-узел? То есть, сделать так, чтобы перехватывающий, подменный узел стал доступен для атакуемого клиента по тому же IP-адресу, который указан в сертификате? Как ни странно, не факт – владение секретным ключом от сертификата никак не помогает в решении сетевой задачи подмены IP-узлов. При этом, если в сертификате сверяется только имя хоста, то атака сработает уже и при подмене DNS. С другой стороны, тот, кто может подменить IP-узел и DNS, может попытаться выпустить сертификат для этих реквизитов. Однако такая подмена уже потребует атаки на системы УЦ, а не на обычного клиента веб-узла.

На одном IP-адресе может размещаться большое количество веб-узлов с разными именами. Но это не является препятствием для того, чтобы вписать для всех этих узлов один и тот же IP-адрес в сертификат. Сертификат может быть выпущен только для IP-адреса. Например, такие сертификаты обещает даже Let’s Encrypt. Но если обращение к узлу происходит в контексте, где нет DNS-имён, то можно использовать сертификат только с IP-адресом, и если бы был возможен контекст, в котором есть только DNS-имя, то сгодился бы сертификат только с именем, как сейчас. Так что тут проблемы нет. Тем более, если сертификаты начинают выпускаться всего на несколько дней.

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

Утечки по побочным каналам (ПЭМИН) возможны разные. Предположим, что есть некоторая портативная радиостанция (рация), которая штатно использует защищённый радиопротокол. Что-нибудь типа P25 – это тут не так важно, главное, чтобы использовался цифровой сигнал, а полезная информация передавалась в зашифрованном виде.

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

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

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

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

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

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

Сообщают, что CA/B-форум принял решение сократить к 2029 году максимальный срок действия TLS-сертификата до 47 дней. В принципе, это давно ожидалось. Скорее всего, могут даже сдвинуть срок раньше, да и максимальный интервал – сократить (дней до 14, скажем). Я в прошлом году писал в заметке о шестидневных сертификатах Let’s Encrypt:

Это нововведение Let’s Encrypt, не сомневайтесь, прямо означает, что браузеры, следом за Chrome/Chromium от Google, постараются оперативно перейти на короткие сертификаты, запретив срок действия дольше месяца (например).

Процесс, скорее всего, коснётся и сертификатов, которые выпускаются от собственных УЦ, не входящих в CA/B-форум.

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

Но необходимо учитывать и другую сторону решения. Сертификаты превращаются в квитанции, разрешающие доступ. Что-то вроде тикетов в каком-нибудь Kerberos. Короткие сертификаты означают, что веб-узлам придётся плотно привязаться к внешней централизованной системе. Те же 47 дней, это даже не три месяца от Let’s Encrypt. Всякий веб-узел должен будет постоянно и в автоматическом режиме отмечаться на центральном сервере, который станет выдавать (или не выдавать) подтверждение, что браузерам всё ещё разрешено к этому веб-узлу подключаться.

Недавно опубликовано очередное сочинение-опус про AI/ИИ и кардинальные изменения в статусе цивизизации к 2030 году: AI 2027 (англ., много букв). Пусть вас не обманывает 2027 в названии – самые радикальные прогнозы там, как сейчас принято, даны на 2030, а в 2027 году только ожидается деятельный суперинтеллект (это, впрочем, менее двух лет осталось ждать).

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

Конечно, в упомянутой публикации используются всё те же шкалы для измерения уровня “интеллектуальности” – способность “писать код” (какой код, зачем?) и способность “быть лучше лучшего из человеков в решении когнитивных задач” (каких именно задач, почему?). А сценарная концепция, кроме типового сейчас требования регулирования и вмешательства правительств, строится на понятии “автономных агентов”, которые, на начальном уровне, “получив инструкцию через Slack или Teams, вносят существенные изменения в код самостоятельно, иногда экономя часы или дни [разработки]”.

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

Впрочем, в тексте AI 2027 некоторые “оценочные суждения” сопровождаются определениями из серии “Что бы это значило?”. И это странные определения, вполне в духе выдачи условного ChatGPT. Например, объяснение того, что имеется в виду, когда пишут про 50-процентное ускорение разработки ИИ-алгоритмов при использовании ИИ, следующее: “50-процентное ускорение – это означает, что [компания] OpenBrain, используя ИИ, достигает за неделю такого же прогресса в исследовании, как она достигла бы за полторы недели без использования ИИ”. Содержательно, да.

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

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

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

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

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

Но самое показательное – это концовки данного произведения. Понятно, что под них и писалось всё остальное. AI 2027 предлагает две возможных концовки. Одна из них – уничтожение всех человеков мощным ИИ в 2030 году при помощи “биологического оружия”; ИИ далее модифицирует под свои нужды планету Земля, колонизирует прочее пространство Солнечной системы и далее, за её пределами, силами роботов.

Другая концовка – объединение всех государств мира под управлением США (да), происходящее в результате локальных переворотов, которые ИИ помогает реализовать (так написано); после чего наступает эра процветания (или милосердия?), человеки запускают ракеты, – для колонизации планет Солнечной системы, а не то что вы подумали, – и всё это с помощью хорошего ИИ.

Иных вариантов, кроме этих двух, сочинение-прогноз не предусматривает. С Днём Космонавтики, как говорится.