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

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

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



Комментировать »

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



Комментировать »

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

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

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

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

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



Комментировать »

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

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

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

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

(Май 2017 г.)



Комментировать »

ИИ-говорилка GigaChat теперь, как бы, умеет английский язык, однако на все запросы через Telegram-бот, потенциально ведущие к показательному “запутыванию контекста”, отвечает в стиле, что “на эти темы не могу разговаривать” (на русском, кстати). В английском, из-за аналитических свойств языка, запутывать контексты LLM заметно сложнее, чем в русском, но тоже можно (простой пример из области ИТ или, другими словами, из речного хозяйства – bank и log, что в не слишком “грамматической” версии для LLM может, например, выглядеть так: “Having logs removed in timely manner keeps bank totally speckless”). Кстати, в английском неплохо помогают гладкие переключения существительное/глагол. Но, конечно, если подозрительные ветки закрываются системным барьером, то и увидеть ничего нельзя. Впрочем, наличие однотипного ответа тоже демонстрирует уровень “интеллекта”.



Комментировать »

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

В той заметке про ИИ в двухщелевом опыте, кроме прочего, написано:

Можно же даже так сделать: электрон попадает в экран детектора, координаты точки автоматически вводятся в нейросетевую систему ИИ, система корректирует собственные предсказания (известная схема). Электроны можно излучать быстро, нейросеть – тоже на быстром компьютерном оборудовании, с большим объёмом памяти. Осталось построить, запустить и ждать – сойдётся ли процесс. А если сойдётся, то выяснится, к чему это приведёт.

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

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



Комментарии (2) »

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



Комментировать »

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



Комментировать »

Чем хороша именно “прочность шампанского” в вопросах для ИИ LLM? Тем, что “прочность” – это ещё и “крепкость”, а “крепкость” – это почти “крепость”, а “крепость” – это и замок, как строение, и характеристика алкогольных напитков. При этом “прочность” – применимо к хлопку (к ткани).

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



Комментарии (1) »

Кстати, ещё немного про Go (Golang). Одна из самых странных особенностей Go – это использование комментариев для управления компиляцией. Например, вот такая директива:

// +build !amd64

– это “обычный” комментарий в исходном коде, но его читает препроцессор и использует указание +build для того, чтобы определить платформу (всё, что не amd64; скажем, так сделано у меня в исходниках ассемблерной реализации “Кузнечика”; современный вариант: “//go:build“). Идея снабдить комментарии двойным дном – довольно богатая, в лингвистическом, так сказать, смысле.

Формально, “// +build !amd64” – это, действительно, комментарий. То есть, здесь обозначено, что строка не относится к, собственно, исходному коду. Это верно. А то, что там потом будет копаться препроцессор – ну так, как бы, и в комментариях бывает написано, что “данная функция нужна только для 8-битной конфигурации, поэтому здесь вызов спрятан в комментарий”. Неявно предполагается, что роль препроцессора играет непосредственно разработчик, а в случае “+build” в Golang – просто этот процесс автоматизируется. Это, конечно, не какой-то там особенный и исключительный случай использования комментариев: вспомните что-нибудь типа “#!/usr/bin/perl”. Тем не менее, ситуация, когда содержание комментария непосредственно влияет на процесс сборки, всё же выглядит необычно.

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

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

Например, на arm64 go-ассемблерное “ADD $8, RSP, R2” соответствует оригинальному “ADD X2, SP, #0x8”. RSP превращается в SP потому, что ассемблер Go использует псевдорегистры, среди которых есть SP (и не только), поэтому совпадающие по названию аппаратные регистры переименованы. Псевдо-SP – это, как бы, указатель стека, но с хитростями: псевдо-SP может иногда совпадать по значению с аппаратным SP, в частности, если на подходящей платформе указана нулевая длина “собственного” стека ассемблерной процедуры (но это детали). При этом, ссылки с использованием смещения от значения псевдорегистра SP должны (это прямо строгое требование Go) оформляться с символьными именами, вот так: len-8(SP), где “минус” это не совсем вычитание, а len – это даже не “синтаксический сахар”, но что-то вроде комментария наоборот, поскольку никакой языковой интерпретации len здесь не имеет, ничего из len не вычитается, да и вовсе не обязательно, чтобы эта строка совпадала с именем аргумента в определении прототипа функции или ещё с чем-то совпадала (или не совпадала). Но если не указать произвольный символьный префикс – компилятор выдаст ошибку. Этому, естественно, имеется историческое объяснение, которое называется Plan 9.

Отрицательные и положительные смещения для SP – тоже отдельная забавная история: если SP совпадает с аппаратным регистром по семантике, – что задаётся правилами определения процедуры и входа в процедуру, – то, на некоторых платформах, можно использовать привычные положительные смещения, вот так: len+8(SP), однако где-то в документации написано (попробуйте найти), что “при ручном кодировании” необходимо использовать (только) “отрицательные смещения”. Да. Ну или наоборот, потому что лучшей документацией тут оказывается исходный код – как самого Golang, так и генерируемый компилятором.



Комментировать »

Воскресное чтение манускриптов. Точнее – иллюстрация с пальмами и антилопой из “Христианской топографии” Козьмы Индикоплова, в варианте из Апостольской библиотеки Ватикана, датируемом девятым веком (н.э).

Picture of palm trees and antelope

Подпись к иллюстрации утверждает следующее:

ΤΑΥΤΑ ΕΙϹΙ ΤΑ ΛΕΓΟΜΕΝΑ ΜΟΖΑ
ΟΙ ΦΥΝΙΚΕϹ ΟΙ ΪΝΔΗΚΙΝΟΙ

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



Комментировать »