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

В алгоритме 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 испытывать не будет: во-первых, это конечное количество; во-вторых, значение локализуется в легко обозримую структуру. Перекликается с идеями о том, что и окружающий кусочек Вселенной – это лишь локализация аспектов из того самого “топоса” (то есть, “галлюцинации”), а невычислимый процесс этой локализации – соответствует интеллекту (может, даже разуму).

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

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

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

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

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

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

И занятно будет посмотреть, кстати, с какими эффектами работа наложенной сети, в ходе развития технологии, переедет в браузеры, которые базируются на Chromium/Chrome, но считаются как бы обособленными и самостоятельными.

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

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

Много публикаций про систему ИИ от Google, которая предсказывает погоду. Интерес СМИ широкого профиля и журналистов тут вполне понятен: комбинация “Google, AI, weather/climate”, в направлении “Технологии”, сейчас одна из мощнейших. Исходная статья достаточно занятная, учитывая “хайп”: там рассказывается, что методы машинного обучения, использующие массив исторических данных погодных измерений, позволили сделать систему предсказания погоды, которая, по некоторым параметрам, превосходит имеющиеся “детерминированные” системы “численного моделирования”. Однако если вы захотите взглянуть на минимально содержательные детали, о которых там речь в действительности, то читать нужно не “заглавную статью”, а Supplementary Materials (но 132 страницы с таблицами и картинками, да).

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