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

В свежей работе от Google DeepMind описывают результаты успешного поиска химических структур для новых материалов при помощи системы с машинным обучением. То есть, “нейросети” и соответствующая им аппаратура используются для оптимизированного перебора, с вспомогательным псевдослучайным вводом. Пространство химических структур велико, а вычисления, требующиеся для моделирования, очень сложны. Что, впрочем, не мешает устроить параллельный перебор и регулировать его итерации при помощи фильтра, который как раз построен на физико-химической вычислительной модели, пусть и простой. Это пример полезной интерпретации свойств ИИ, который существенно отличается от случая, когда выдачу, генерируемую LLM, принимают за работу “инструмента для анализа данных” по запросу-затравке или используют для “краткого пересказа”. Это, впрочем, не отменяет проблему “чёрного ящика”, выдача из которого не помогает улучшить вычислительные модели.

В журнале “Интернет Изнутри” опубликована моя статья “Протоколы в туннелях и будущее Сети на примере DoH и ECH“:

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

На сайте ТЦИ опубликована моя статья про технологию DKIM (а также – DMARC и SPF, которые связаны с DKIM):

“DKIM – Domain Keys Identified Mail (дословно: «почтовая идентификация по доменным ключам», RFC 6376) – технология, позволяющая проверить полномочия почтового сервера, который доставляет почтовые сообщения (email) из того или иного почтового домена. Это основанный на электронной подписи способ аутентификации технического отправителя, который помогает решать задачи обнаружения писем с «поддельным» адресом отправителя”.

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

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

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

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

В алгоритме ECDSA есть число, обычно обозначаемое k, которое используется при вычислении значения подписи, а именно – k определяет параметр r из пары (r,s) подписи. Значение r из этой пары необходимо для того, чтобы сошлась формула проверки. В исходном алгоритме k предлагается выбирать случайным образом (но без повторов, и держать в секрете). Дело в том, что если третья сторона знает k, то она может элементарным способом вычислить секретный ключ по сообщению с подписью; повторное использование k для разных сообщений, при прочих равных, так же приводит к раскрытию секретного ключа.

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

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

Так что проблем с псевдослучайным параметром в ECDSA много. На практике, в алгоритм вычисления k так или иначе подмешивают дополнительные значения, не ограничиваясь лишь выдачей генератора псевдослучайных чисел. Это полумера. Однако есть и полностью детерминированный вариант (“deterministic ECDSA“), в котором значение k вычисляется для конкретного сочетания сообщения и секретного ключа (например, такой алгоритм поддерживается свежим OpenSSL 3.2).

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

Продолжается PR-акция OpenAI, теперь пишут, что там сделали особо продвинутую систему ИИ LLM, которая настолько всех удивила, что вызвала опасения и, собственно, даже “круговые перестановки управляющих”. СМИ сообщают, что новая модель решает задачки:

“The model, called Q* – and pronounced as “Q-Star” – was able to solve basic maths problems it had not seen before” (“Модель […] способна решать простые математические задачи, которые не встречала ранее”).

(Q – кстати, занятное название, литературное.) Интересно, что решать “простые математические задачи” умеют системы компьютерной алгебры и, в частности, WolframAlfa (проверьте). А самое занимательное, что для человека, мало знакомого с предметом, удивительным оказывается, что системы компьютерной алгебры прекрасно решают типовые студенческие задачи “высшей математики” (потому что там почти весь аппарат сводится к хорошо формализуемым компьютерным операциям).

На OpenNET пишут про RFC для децентрализованной системы имён GNS:

“Использование Curve25519 воспринимается некоторыми как весьма странный шаг, так как для ECDSA применяют другие типы эллиптических кривых, а в паре с Curve25519 обычно используют алгоритм цифровых подписей Ed25519, более современный, более безопасный и более быстрый, чем ECDSA. С точки зрения криптостойкости в том числе вызывает сомнение выбор размера закрытого ключа – 32 байта вместо 64 байт”

В GNS, действительно, используют ECDSA на кривой Curve25519. Это может, конечно, показаться странным. Однако алгоритм ECDSA работает в группе точек и вообще не зависит от выбора кривой (да, даже про “суперсингулярные кривые” тут есть занятные уточнения). Поэтому ничто не мешает взять Curve25519 вместо, например, более привычной P-256. Какие-то сугубо математические свойства Curve25519, типа наличия кофактора и т.п., вовсе и не являются необычными – такие кривые вполне себе подходят и для ECDSA. Так что, если нет доверия той же P-256, но нужен именно алгоритм ECDSA – можно взять Curve25519. Использование же Ed25519 в данном протоколе невозможно из-за особенностей преобразования ключей, о чём, собственно, сказано в RFC. Насчёт “более быстрого” алгоритма Ed25519 – это, в основном, определяется как раз параметрами кривой (поле и т.д.).

Что касается странного дополнения про 32-байтовый и 64-байтовый ключи: тут, наверное, что-то перепуталось на каком-то этапе пересказывания. В Ed25519 секретный ключ – 32-байтовый. И в ECDSA на P-256 (например) – тоже 32-байтовый. Потому что разрядность в 256 бит (32 байта) делает бессмысленным использование секретных ключей большей длины: всё равно значение сократится. А 64 байта – это общий размер подписи, а не ключа.

Можно предположить, что тут ещё сыграло следующее популярное заблуждение, которое нередко наблюдается в отношении SSH-ключей: многие считают, что, например, поскольку открытый ключ Ed25519 короче, чем ECDSA на той же P-256, он поэтому и менее “криптостойкий”. Действительно, для ECDSA/P-256 открытый ключ обычно записывается в 64 байта (иногда чуть меньше, иногда – чуть больше, зависит от кодирования), а в Ed25519 – только в половину, в 32 байта. Однако эти 64 байта ECDSA математически эквивалентны 32 байтам, там половина байтов приносит только один бит дополнительно: открытый ключ представляет собой точку на кривой, у точки – две координаты (X,Y), каждая по 32 байта, и вот полная форма записи ключа ECDSA подразумевает указание объединения X и Y, откуда и получается 64 байта; однако можно указывать только одну координату (X), а вторую (Y) – вычислять из уравнения кривой при необходимости. В такой схеме, для ECDSA, потребуется сохранить дополнительно знак, это один бит, и получается тоже около 32 байтов для записи открытого ключа. А вот в Ed25519 алгоритм предписывает всегда использовать только одну координату (ну, строго говоря, там есть ещё некоторые преобразования, но здесь они не важны). То есть, математически эти ключи совпадают по представлению, отличие тут чисто прикладное, поэтому дополнительные 32 байта записи для ECDSA не делают даже открытый ключ в два раза длиннее “криптографически” – он всё равно 256-битный (по разрядности кривой).

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

Надо сказать, я несколько лет назад отмечал, что интересно будет посмотреть, внедрит ли Google поддержку ESNI в свой браузер. Интерес, на мой взгляд, тут происходил из того, что Google последовательно отказывался поддерживать такие технологии обеспечения безопасности, которые использовали тот или иной независимый инструмент управления криптографическими ключами в TLS. Примеров два: изгнание из веба DANE (отпечатки ключей/сертификатов в DNS, для сверки с предъявляемыми сервером) под предлогом замены на Certificate Transparency (которая хоть и полезная, но о другом, так как не может предотвратить использование валидного подменного сертификата в момент соединения); отключение HPKP (запоминание отпечатков серверных ключей клиентом, как в SSH).

И вот я предположил, что, вероятно, ESNI тоже не будет в Google Chrome. Но сейчас вышло иначе: вместо исходного варианта ESNI – Google Chrome (Chromium) всё же поддержал ECH, а это развитие ESNI, гораздо более продвинутое. Впрочем, думаю, что в этой “продвинутости” и состоит причина поддержки: всё же, ECH далеко ушла от первоначальной идеи ESNI – позволяет реализовать доступ к скрытым сервисам, при этом наследует доверие системе хорошо известных удостоверяющих центров (“имени CA/B-форума”); впрочем, ECH и ключи для дополнительной защиты внутри TLS позволяет публиковать, например, в DNS, то есть, не централизованным способом, который, формально, не зависит от браузера (но нельзя забывать о встроенной поддержке DNS-over-HTTPS с заданными провайдерами). В общем, поддержка внешних ключей появилась, но теперь нужно посмотреть, как будет она развиваться: ведь доверенные ключи для ECH могут приезжать и вместе с браузером – это важная особенность.

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

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

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

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

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

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