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

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

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

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

Если вспомнить математическую часть алгоритма, то речь про вычисление y = A^x (mod M). Обратите внимание на значение A (натуральное число), которое задаёт конкретную схему аппарата для запуска алгоритма Шора! При последовательном вычислении y = A^x (mod M), если показатель x пробегает достаточное количество значений, результат (y) начнёт повторяться, это теоретико-числовая польза от алгоритма, потому что позволяет определить, при каком x A^x == 1 (mod M) и т.д., этому как раз соответствует период данной функции, который мы хотим определить квантовой машиной. Конечно, в случае квантовой машины, никаких подобных вычислений нет: такая машина – супераналоговый прибор, возможно, что ламповый, но скорее холодный, чем тёплый: выход в квантовую ирреальность почему-то требует низких температур. В общем, не предполагается, что происходят какие-то шаги, кто-то переключает реле и сигналы, а на вход “блока функций” поступают разные “иксы”, пусть даже и параллельно. Нет, напротив, подключается несколько миллионов (предположим) загадочных “гейтов”, объединённых в схему, задающую функцию для проверяемого значения A, и всё – предполагается, что в финальном измерении через схему пройдёт поток вероятности, который преобразуется нужным способом и выльется во второй регистр.

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

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

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

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

(См. также про алгоритм Шора и Вселенную кубиками.)

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

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

Пока что с Firefox это не сработало: пользователи всё поняли правильно и даже возмутились. Не факт, что это будет иметь долгий эффект: интернеты становятся “корпоративными”, в том числе, на стороне клиента. Нужно ли ожидать рекламных пауз в ядре Linux? Риторический вопрос.

Попытаться построить квантовый компьютер на тысячи кубитов имеет смысл хотя бы для того, чтобы проверить, что имеющиеся модели работают для больших пространств состояний. Попытка факторизации 1024-битного числа на гипотетическом квантовом компьютере при помощи алгоритма Шора сталкивается с необходимостью как-то действовать в пространстве из 2^1024 состояний (ну, предположим). Влезет ли такое количество состояний во Вселенную? Насколько 2^1024 вообще большое?

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

Существенно ли (2^80)! превосходит 2^1024? Может показаться, что 2^1024 очень большое число. Однако провести сравнение нетрудно. Заметьте, что при вычислении факториала каждое чётное число повышает степень двойки (иногда – больше чем на единицу), поэтому 2^1024 вкладывается уже в 1026! (ну или примерно так; 1026 = 1024+2, проверьте; естественно, 171! больше 2^1024). Что уж говорить про (2^80)!! (Здесь второй восклицательный знак обозначает восклицание.) Теперь может показаться, что 2^1024 не такое уж и большое число, чтобы не вкладываться в качественно нарезанную Вселенную.

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

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

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

В быту 3D-принтер полезен тем, что можно напечатать разные уникальные изделия, “оптимизированные” для решения конкретной задачи. Например, я напечатал ремонтную деталь для блока кнопок управления автомобильным креслом: можно было бы заменить весь блок целиком (хорошо, что не кресло), но это потребовало бы снятия кресла – достаточно много работы. Это далеко не единственный пример. Так, из недавнего, я спроектировал и распечатал несколько установочных кронштейнов для крепления небольших солнечных батарей (для питания уличных светильников), кронштейн для установки самого светильника под скатом крыши, несколько элементов крепления видеокамер, немало коробок-корпусов для разных самодельных устройств вроде цифровых термометров и часов с GPS-коррекцией, несколько защитных кожухов для различных простых механизмов (вроде замка уличной калитки) и другие подобные изделия. Модели я готовлю в OpenSCAD, это очень удобно. Сейчас я в основном использую FDM-принтер Anycubic Mega X – о чём рассказано в отдельной заметке (с картинками). Этот принтер работает методом последовательного наплавления слоёв пластика, то есть, он состоит из нагреваемого столика, над которым перемещается печатающий узел с горячим соплом (“хотэндом”) экструдера.

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

Основные проблемы всегда доставляют участки модели, которые нависают над столиком. Очевидно, что FDM-принтер не может печатать “в воздухе” – пластик будет просто вытекать вниз. Обычно, для того, чтобы печатать “нависающие” поверхности, используются подпорки. Подпорки здесь – это достаточно лёгкие структуры, которые принтер печатает, начиная от столика, и которые потом можно удалить, отломив или отрезав от изделия. Подпорки добавляются в описание модели для печати. Слои основного изделия, соответственно, накладываются на подпорки. Убирать подпорки, например, у резьбы – весьма сложно: смысл теряется. (Бывает ещё вариант с печатью подпорок другим типом пластика, например, водорастворимым, но для этого принтер должен иметь два печатающих узла.)

Так вот, у всякого FDM-принтера, тем не менее, есть некоторая “степень нависания” слоя, которую принтер может распечатать без подпорок, если только соответствующая часть изделия “вырастает” из другой части, а не висит уж совсем отдельно. Это объясняется достаточно просто: если очередной слой лишь немного “свешивается” за край предыдущего, то свежий пластик успешно приклеивается к этому краю и не провисает, так как застывает достаточно быстро (тут главное не использовать ни слишком высокую скорость движения печатающего узла, ни слишком низкую). Это отлично работает как для резьбы, печатаемой вертикально, так и для других моделей (в принципе, можно даже печатать небольшие горизонтальные “прогоны”, на небольшой скорости). Что, собственно, и составляет один из методов оптимизации: углы “нависания” нужно проектировать так, чтобы принтер справился без подпорок. Да, это вводит ограничения на конструкцию изделия, поэтому может составить проблему, если использовать готовую модель. Однако если модель проектируется под конкретную задачу с нуля, этот момент можно учесть, что, в общем-то, является обычным технологическим аспектом разработки (не только в случае 3D-печати).

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

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

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

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

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

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.

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

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

Предположим, что некоторые интернет-измерения, проводимые с использованием веба, полностью основаны на уникальном имени хоста, которое генерируется под каждый запрос. Это очень удобный способ создания информативного маркера, переходящего между протоколами. Имя нетрудно встроить, например, в адрес источника файла изображения, ссылка на которое входит в состав кода веб-страницы. Почему подходит именно имя хоста? Потому что оно же будет использоваться клиентом и в DNS, и в HTTP. А вот часть URL, соответствующая адресу документа, уже в DNS не ходит. Другими словами: используем в браузере (условный) URL https://123dio.cba.example.net/an-img.gif, где полезные данные кодируются в части 123dio.cba. Строка 123dio.cba.example.net отправится и в DNS, где будет узнана специальным сервером, и в HTTP, а вот an-img.gif – в DNS не попадёт, а поступит только на веб-сервер, отвечающий под 123dio.cba.example.net. Соответственно, насыщение HTTP-запросов полезной информацией, которую мы хотим видеть и в DNS, должно происходить через имена хостов.

Однако возникает неприятная проблема с HTTPS: дело в том, что для установления соединения с браузером сервер под “странным” именем 123dio.cba.example.net должен предъявить TLS-сертификат, валидный для этого имени, но имя-то каждый раз разное, поэтому сертификатов не напасёшься (если их выпускать через тот или иной УЦ, признаваемый браузерами). Использование открытого HTTP тут не рассматриваем – такие условия: хотя бы потому, что страница-носитель загружается по HTTPS. Что можно сделать? А можно, например, совсем отказаться от установления TLS-соединения на стороне сервера и при этом не потерять полезных данных. Нам не требуется реально обрабатывать HTTP-запрос и возвращать файл изображения, нам нужно только зафиксировать на сервере имя хоста, а это имя в HTTPS/TLS передаётся клиентом в начальном сообщении, да ещё и в открытом виде (это как раз и есть SNI TLS). Так что серверный сертификат тут просто не нужен: сервер записывает имя хоста из SNI и – прерывает соединение с тем или иным кодом ошибки TLS.

(Дополнение – 30/04/2023: в комментариях справедливо указывают на wildcard-сертификат для имён вида *.example.net. Однако тут такой сертификат не сработает, поскольку для DNS-части измерений важны кодирующие имена минимум в двух уровнях, то есть, *.*.example.com, а wildcard-сертификат закрывает только один уровень. Несколько уровней – входят в качестве требования в изначальную задачу, оставшуюся здесь за скобками.)

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

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

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

Омоглифы – это символы, совпадающие по начертанию, но различные по значению (интерпретации). Например, Н, H и Η, а именно – заглавная кириллическая “н”, заглавная “h” английского алфавита и заглавная “η” греческого алфавита. Пришлось тут столкнуться с забавной “программной” интерпретацией данного явления. Пакет Gitea (это пакет для работы с исходным кодом в git, с веб-интерфейсом и прочими полезными функциями) при попытке посмотреть некий русскоязычный текстовый файл из репозитория на сервере – показывал мне в браузере предупреждение, что “This file contains ambiguous Unicode characters!” (“Этот файл содержит “неоднозначные” символы Unicode!”). И действительно, встроенный фильтр подсвечивал буквы вроде “a”, “T” и “о”, но не во всех случаях. Так, целиком подсвечивалось сочетание букв “То” из “То есть”. А в другом месте этого же текста подсвечивалась одинокая буква “а”, при помощи которой обозначался союз “а”.

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

(Уточнение: под “словами” подразумеваются последовательности омоглифов, обособленные пробелами.)

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

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

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

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