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

“Люди настолько обленились с этим ИИ, что уже и капчу самостоятельно решить не могут”.

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

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

Две капчи. Сопоставление по утилитарному назначению. Да, тут можно догадаться, наверное, методом исключения. Особенно, на картинке справа: медведь вряд ли подходит к кукольной мебели – выбираем радиоуправляемую машинку типа “монста-трак”. Нет? Не сработало?

Ещё две. Я попробовал, будут ли трудности у ChatGPT (GPT-4o) с этими капчами. Левую капчу я разделил на два блока – с чашкой и всё остальное. Показал ChatGPT сперва картинку чашки, спросил, что нарисовано, получил подробный и верный ответ. Потом показал вторую часть (блок картинок с вариантами) и спросил, может ли ChatGPT найти то, что звучит так же, как чашка, при падении (на английском, по привычке, но, думаю, это не важно здесь). GPT-4o справилось примерно за секунду – ответ: все бутылки звучат так же, как чашка.

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

А это уже больше похоже на какой-то тест Роршаха. Видимо, всё же нарисована лягушка. Почему лягушка должна подходить к варану-крокодилу (или что это?), а не к утке, у которой на спине камера от “гугломобиля”? Наверное, опять методом исключения. Дальше – сложнее.

Числа? Похоже, что вверху слева – это 0.

Перечитайте вопрос: чем тут можно писать? Карандашей или мелков – на картинках нет. А на клавиатуре – печатают.

Dual EC DRBG (“Сдвоенный детерминированный генератор случайных битов на эллиптической кривой”) – нашумевшая схема генератора псевдослучайных чисел, в которой встроен (потенциальный) математический бэкдор. Несмотря на сразу же возникшие подозрения о бэкдоре, эта схема была без проблем стандартизована NIST в 2006-2007 годах и достаточно широко использовалась. Соответствующий стандарт позже официально отозван NIST.

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

Важнейшей особенностью криптографических генераторов (псевдо)случайных чисел является то, что выдача генератора детерминирована внутри – то есть, выдаваемые значения определяются внутренним состоянием (пояснение от 28/01/26: это только для внешнего наблюдателя генерируемая последовательность выглядит как случайная). Именно этот аспект служит фундаментом для построения бекдора в Dual EC DRBG. Криптографические генераторы псевдослучайных чисел имеют важнейшее значение не только для теоретической, но и для прикладной криптографии – это краеугольный камень всех практических систем криптографической защиты.

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

По сути, бэкдор в Dual_EC_DRBG – это реализация протокола Диффи-Хеллмана (DH) на эллиптической кривой: секретный ключ находится у стороны, контролирующей бэкдор через параметры протокола, что позволяет этой стороне получать внутреннее состояние генератора псевдослучайных чисел, наблюдая его выдачу. Знание внутреннего состояния приводит к раскрытию всей последующей выдачи генератора. При этом, математически, пользователь Dual EC DRBG неявно выполняет обмен DH с контролирующей параметры генератора стороной. Это важное свойство штатных схем построения “надёжных бэкдоров”: доступ к бэкдору должен быть только у той сторны, которая знает секретный параметр – секретный ключ. Есть и другое важное свойство: если секретный параметр не был раскрыт, то строго доказать, что бэкдор действительно встроен в конкретную реализацию – нельзя. Это не отменяет возможности тсрогого описания для механизма такого бэкдора.

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

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

На схеме: S_n – внутренние состояния генератора; φ() – функция, преобразующая состояние S_n в S_n+1; ξ() – функция, преобразующая состояние S_n в выдачу генератора B_n на данном шаге. Биты пошаговой выдачи B_n могут конкатенироваться для получения псевдослучайной последовательности нужной длины (на схеме: RND[…]) – это типовой способ прикладного использования генератора.

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

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

Математической особенностью описываемого бэкдора является то, что он вовсе и не позволяет обратить функции ξ и φ – они остаются односторонними, но бэкдор открывает возможность простого вычисления следующего внутреннего состояния генератора по известной выдаче ξ. Это возможно потому, что алгоритм содержит дополнительную структуру, связывающую функции ξ и φ.

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

Dual EC DRBG работает на эллиптической кривой (над конечным полем), а в качестве односторонних функций использует умножение точки эллиптической кривой на скаляр: x∘P. Далее умножение на скаляр обозначается “блобом” (∘). Стойкость к обращению здесь основана на задаче дискретного логарифмирования: то есть, по значению Q = x∘P – вычислительно трудно найти x.

Вспомним, что умножение на скаляр – обычное для эллиптической криптографии последовательное сложение точки кривой с самой собой. Сложение – операция, которая введена на точках кривой. А именно: точкой кривой называется пара (X, Y) значений “координат”, соответствующих уравнению кривой. Здесь X и Y – это элементы подлежащего конечного поля, которое входит в параметры криптосистемы. В данном конкретном случае (например, для кривой P-256) используемое конечное поле – это вычеты, то есть “остатки” по модулю простого числа. Сложение точек P + Q = R позволяет по паре координат точки Q (X_Q, Y_Q) и паре координат точки P (X_P, Y_P) Получить координату точки R (X_R, Y_R). Скаляр – это целое число. Умножение на скаляр 3 означает, что точка складывается сама с сбой в трёх экземплярах: 3∘P = P + P + P (плюс – это сложение точек). По такому сложению точки всякой эллиптической кривой всегда образуют группу (по определению эллиптической кривой).

В алгоритме Dual EC DRBG используется две точки кривой: P и Q. Точка P – задаёт последовательность внутренних состояний. Внутреннее состояние S_n в Dual EC DRBG – целое число, которое соответствует координате X точки кривой, полученной умножением P на значение предыдущего состояния, как на скаляр. Вторая точка, Q – задаёт “ответвления”, то есть, выдачу генератора по каждому из состояний, и используется в качестве основания на каждом шаге. Ниже представлена упрощённая схема Dual EC DRBG.

На этой схеме: S_n – внутреннее состояние; для получения следующего состояния из текущего – точка P умножается на значение состояния (скаляр: S_n∘P), а координата X получившейся точки – выводится в качестве нового состояния генератора; для вывода случайных значений – вторая точка, то есть – точка Q, умножается на состояние (S_n∘Q) и выводится координата X получившейся точки. То есть, используется две одинаковых функции с разным основанием: P и Q. Раз стойкость этих функций основана на дискретном логарифмировании, то они односторонние, как и требуется.

Математический смысл бэкдора не нарушает стойкость конкретных операций с точками P и Q, он несколько хитрее и строится на в соотношении между точками P и Q. Допустим, атакующей стороне известно такое значение δ, что P = δ∘Q. Выдача генератора – это X-координата точки S_n∘Q. Атакующий находит подходящую Y-координату, подставив значение в уравнение кривой (точек с подходящими координатами будет две, алгоритм знак координаты Y не различает, но выбор точки, очевидно, не представляет труда). Таким образом атакующий легко восстанавливает точку кривой, подходящую для выдачи генератора. Далее – умножаем на δ.

δ∘(S_n∘Q) = S_n∘(δ∘Q) = S_n∘P   (1)

Рассмотрим формулу (1) подробнее. Почему она работает? Потому что скаляры – это целые числа. Из-за коммутативности группы точек кривой к скалярам применимы арифметические свойства целых чисел. В алгебре такая конструкция называется ℤ-модулем. Всякая коммутативная группа является ℤ-модулем. (Некоторые алгебраисты из-за этого даже не считают коммутативные группы “настоящими” группами.) Применительно к эллиптической кривой: 3∘P = P + P + P, а 5∘P = P + P + P + P + P. Но тогда (3+2)∘P = 5∘P = P + P + P + P + P, что следует из свойств групповой операции – просто поставим скобки: (P + P) + (P + P + P), получив, таким образом, две точки (P + P) = 2∘P и (P + P + P) = 3∘P. 3∘P + 2∘P = 5∘P. Обратите внимание, что здесь знак “плюс” используется в двух значениях: и для обозначения сложения точек кривой, и для обозначения привычного сложения в целых числах (3+2). А раз схема работает для сложения целых чисел, то она обязательно работает и для умножения целых чисел, потому что умножение в целых числах можно построить через сложение (собственно, при корректном преобразовании 0 и 1, сложение и умножение в целых числах просто могут быть переведены одно в другое, как операции). Но тогда и (3*2)∘P = (P + P) + (P + P) + (P + P) = 3∘(2∘P) = 6∘P. Что и используется в формуле (1), вместе с коммутативностью умножения в целых числах: 2 * 3 = 3 * 2.

Таким образом, атакующая сторона, которая знает секретный скаляр δ, получила значение следующего состояния генератора, вычислив Χ-координату точки S_n∘P (см. схему). Формула (1) вообще очень похожа на реализацию протокола Диффи-Хеллмана (DH) на эллиптической кривой. То есть, пользователь генератора псведослучайных чисел, можно сказать, обменялся с атакующей стороной открытыми параметрами Диффи-Хеллмана. А именно: открытый параметр атакующей стороны, статический ключ, зашит в константы протокола – P = δ∘Q, где секретный ключ – δ; открытый параметр DH пользователя – это динамическая выдача основного алгоритма – S_n∘Q, где секретный ключ S_n. “Открытые параметры DH” пользователя атакующая сторона наблюдает в трафике. Важное отличие от практического DH состоит в том, что “общий секрет” тут не должен становиться “общим” с атакующей стороной.

Итак, для внедрения бэкдора нужно выбрать такие P и Q, что P = δ∘Q. Полученные точки – это параметры конкретной реализации алгоритма, но они могут быть закреплены в стандарте (что и было сделано). Но в спецификации Dual EC DRBG для кривой P-256 в качестве точки P строго указана базовая точка группы кривой, которая используется в спецификации P-256. То есть, произвольно выбрать P нельзя. Оказывается, в том случае, если одна из точек P или Q заранее строго задана, то определить нужное значение δ можно при помощи вычисления мультипликативного обратного по модулю порядка группы точек. Важно, чтобы порядок был простым числом. Но это стандартная практика для прикладной криптографии. Например, для кривой P-256 – соответствующий порядок простой.

Чтобы получить бэкдор, нужно определить δ из P = δ∘Q. Может показаться, что если точка P зафиксирована, – соответственно, выбрать эту точку умножением какой-то точки Q на произвольный скаляр нельзя, – то требуется решить сложную задачу отыскания дискретного логарифма. Но это не так, поскольку мы всё равно можем выбрать произвольную точку Q. Чтобы согласовать точки, возьмём произвольное значение ε в интервале от 2 до порядка группы, генерируемой P, а потом возьмём δ = ε^(-1) по модулю порядка. Пусть порядок P – то есть, количество точек в используемой группе, – это простое число n. Тогда нужно найти ε * δ = 1 (mod n). (Например, 2 – обратный по умножению элемент к 4 по модулю 7, так как 2 * 4 = 1 (mod 7).) Задача нахождения мультипликативного обратного по модулю простого числа здесь вычислительно несложная. Определив δ = ε^(-1), в качестве точки Q выберем ε∘P. Тогда: δ∘Q = δ∘(ε∘P) = (ε^(-1)*ε)∘P = P. Следовательно, мы нашли такое δ, что P = δ∘Q.

То есть, если можно выбрать оба параметра – точки P и Q, – то выбираем так, что P = δ∘Q, а если одна из точек зафиксирована – выбираем δ = ε^(-1) по модулю (простого) порядка группы точек, это всегда можно сделать из-за особенностей спецификации: подлежащие группы имеют простой порядок. (Не забывайте, что в формулах выше используется два умножения – умножение точки на скаляр и умножение целых чисел (δ = ε^(-1); 1 = ε^(-1)*ε). Это работает потому, что скаляры – целые числа, но по модулю порядка группы.)

В Dual EC DRBG битовый вывод генератора, – то есть, X-координата S_n∘Q, – урезается: из него удаляются 16 старших битов. Это означает, что прямо использовать результат для вычисления координат исходной точки нельзя. Но 16 бит можно быстро перебрать, проверяя, для всех значений подряд, лежит ли на кривой точка с соответствующей X-координатой. Вычисление значений по уравнению кривой тоже не составляет проблемы – уравнение известно, а используемые там операции обязательно быстрые.

Естественно, полученная перебором точка может оказаться неверной. То есть, точка не будет являться S_n∘Q. На этом шаге “через бэкдор” у атакующего нет никакого способа проверить, что точки совпали. Но это не сильно затрудняет атаку. Значения секретного состояния нужно вычислить для всех возможных точек, которые соответствуют сокращённому битовому значению, а результат по каждой точке – сопоставить с дальнейшим анализом трафика. Например, если выдача генератора используется для получения секретного ключа, то выбрать его верное значение можно при помощи пробного расшифрования. В любом случае, анализ 2^16 числовых значений при помощи перебора не представляет здесь вычислительной проблемы.

В ранней версии стандарта NIST на Dual EC DRBG реализация использовала подмешивание дополнительной маски на каждом шаге вычисления псевдослучайных чисел. Это делало описанный бэкдор нерабочим. Однако стандарт был быстро обновлён, точка подмешивания дополнительной маски перенесена, и использование бэкдора стало снова возможным. Поэтому данная особенность здесь не рассматривается.

Проблема алгоритма Dual EC DRBG, как криптографического генератора псевдослучайных чисел, помимо низкой производительности, в том, что внутри его конструкции есть жесткая структура, зависящая от внешних параметров. Из-за алгебраических свойств эллиптических кривых, в практической реализации – точки P и Q всегда связаны. Да, иногда, если специально постараться, они могут быть получены способом, дающим некоторую гарантию того, что связующий скаляр никому не известен. Либо, P и Q может генерировать конкретный пользователь, в качестве параметра для своей локальной версии генератора. Стандарт NIST разрешал такой вариант, но не рекомендовал его, а для соответствия строгим требованиям FIPS допускались только параметры из спецификации.

(Это расширенная версия статьи, которую я недавно опубликовал на “Хабре”.)

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

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

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

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

Почему так получилось? Формально, и двоичный, и десятичный вариант – отображают цифры. Но в двоичном варианте цифр требуется всего две, и одну из них обозначает выключенный светодиод. А вот в десятичной системе с индикаторами на сегментах – нужно десять цифр, и у этих цифр появляется необходимая пространственная конфигурация (двумерная): “рисунок” цифры {0, 1, 2, 3, 4…}, который и позволяет наблюдателю отличать одну цифру от другой.

Поэтому можно считать, пусть и несколько условно, что упомянутая выше двоичная схема отображения на светодиодной линейке – ближе к самому отображаемому числу, а вот схема с индикаторами – ближе к отображению цифр. Для десятичных цифр нужно больше структуры. Однако, во-первых, эта структура возникает в представлении разумного наблюдателя; во-вторых, конфигурации сегментов индикаторов всё так же можно легко сопоставить с числами {0,…,255} попарно. То есть, с точки зрения схемотехники, да, стало больше элементов, но количество состояний схемы осталось тем же, что и в случае светодиодной линейки. Структура, необходимая для понимания цифр, добавилась, а количество состояний – не увеличилось. Всё потому, что никакого процесса счёта и записи чисел цифрами – в схеме нет. Это лишь интерпретация. Интеллектуальная интерпретация. Но реализуется она не на схеме.

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

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

Немного древних чисел. На скриншоте ниже – глиняная табличка из Месопотамии Plimpton 322, которую датируют 1900-1600 годом до нашей эры.

Image: CDLI / Rare Book and Manuscript Library, Columbia University, New York, New York, USA

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

Попробуем прочитать числа в середине таблички (примерно – в середине: найти исходное положение фрагмента нетрудно, если воспользоваться характерным пятном).

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

Итак, если записать в принятом формате, обозначая шумерские цифры числами [01..59] в десятичной записи и разделяя позиции точкой, получатся числа, которые представлены ниже (два числа, слева направо, строка с зелёными подсказками).

38.11     59.01

Чтобы понять, как такие значения получаются – посчитайте “галки” и “палки” на картинке: например, три “галки” слева – это 30. Остальное должно сложиться само. Но это шестидесятеричная запись. Её, впрочем, нетрудно перевести в десятичную (учитывайте, что это позиционная система, поэтому цифровые значения умножаются на 60 в степени номера позиции, начиная с нуля; в этом примере – позиций только две).

38*60 + 11 = 2291
59*60 + 1 = 3541

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

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

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

На “Хабре” я вчера опубликовал небольшой разбор математической части (потенциального) бэкдора, который присутствует в Dual EC DRBG (это алгоритм генератора псевдослучайных чисел; он, собственно, широко известен именно по причине обнаружения бэкдора, которое ничуть не помешало стандартизации NIST). Возможно, как-нибудь сделаю отдельную заметку по этой же теме на dxdt.ru (если будет ресурс).

P.S. Кстати, регулярно неверно переводят “Dual Elliptic Curve” из названия на русский – как “Двойные эллиптические кривые”. Но это не “двойные кривые” – кривая там одна, да и чисто грамматически, на английском, это никак не может быть “двойными кривыми”, – а “двойные” или “сдвоенные” – точки: алгоритм использует две точки кривой для получения псевдослучайных значений, отсюда и dual в названии.

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

На папирусе (точнее, на кусочке папируса) P.Mich.Inv.6972 (датируется вторым веком до н.э.), который представлен на скриншоте ниже, как раз пример отличающегося в некоторых деталях текста.

Здесь две колонки – левая и правая. Они соответствуют строкам 421-434 и 445-460 десятой книги (песни) “Илиады”. При этом, например, слово из первой строки папируса – ἐπιτρωπῶσι (“доверяют”) – хоть и укладывается в Venetus A (см. ниже), но это другое слово: на Venetus A используется ἐπιτραπέουσι (“вверяют”/”вверямши”). И там, и там – строка заканчивается одинаково: φυλάσσειν (“сторожить/охранять”). Соответствующий фрагмент Venetus A (я отметил строку 421 и упомянутое слово):

Увеличенный фрагмент папируса с повышением контраста:

И это не только не единственное расхождение, но и не самое существенное: так, на этом же папирусе присутствует совсем другая версия строки 433 (тема для отдельной заметки). То есть, как минимум, более древние записи сильно расходились с “современным” древнегреческим текстом.

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

Некоторое время назад я написал на “Хабр” о попытке использовать ChatGPT для генерирования кода OpenSCAD: задача была – сгенерировать код, описывающий простейший Y-образный разветвитель шлангов; для этого я составил подробнейший “промпт” на естественном языке (есть в статье).

Конечно, выдача ChatGPT оказалась абсолютно бесполезной – в статье есть скриншоты рендеринга того, что сгенерировала LLM. В комментариях спросили, почему я выбрал “чат-бот”, вместо “специализированной модели”. Скопирую сюда свой подробный ответ, чтобы он не потерялся:

Есть целый ряд причин.

Во-первых, эта штука не написала в ответ, что, мол, “вижу, тут требуется 3D-объект, но я всего лишь чат-бот – обратитесь к специализированной системе”. Напротив – оно прямо и уверенно пишет, что точно умеет в OpenSCAD, знает все детали, приводит примеры (я спрашивал), а также предлагает проверить, что всё в коде корректно и верно при помощи рендеринга в OpenSCAD (да, такой вот “напор” демонстрирует). Опять же – что такое “чат-бот”? Если это средство занять назойливых клиентов в чате технической поддержки пустопорожним переливанием запроса в ответ – ну, да, тогда с OpenSCAD лучше не подходить. Но позиционируется-то этот инструмент явно иначе.

Во-вторых, не то чтобы была у меня какая-то уверенность, но я предположил, что в эту систему, – возможно! – уже успели-таки встроить “специализированное решение для 3D”. Это разумное предположение: такая возможность, без сомнения, полезна, системы постоянно обновляют, ждут в этом году “универсальный ИИ”, то и дело утверждается, что оно успешно решает задачи по геометрии на уровне “продвинутого старшеклассника”. Вот и проверили. Если бы оно справилось, это бы не сделало его интеллектом, но результат бы порадовал.

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

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

Наконец, в-пятых: в качестве специализированной системы – я бы всё же предпочёл использовать тот или иной готовый инструмент для параметрического задания типовых объектов в OpenSCAD (Y-образный адаптер к ним тоже относится). Такие инструменты есть. Они детерминированы. Они проще. Натыкать в интерфейсе размеры – быстро. Но они – не LLM, на которых обещают “универсальный интеллект”. Собственно, есть ведь и немало инструментов “визуального программирования”. Даже для специальных систем, типа GNU Radio, но почему-то сейчас про них вообще забыли, а рассказывают именно про генерирование кода LLM, на которые всех заменят.

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

(Source: Wikimedia)

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

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

Вообще, “коммутативность” тут именно в кавычках, поскольку математическая структура несколько сложнее. Запишем операцию в виде формулы, где “*” соответствует смешиванию красок и действует слева: α * G – означает, что секретная краска α смешана с краской G (чтобы как-то обосновать “левое и правое” действие – считаем, что колер α добавлен в банку к краске G). Тогда: β * (α * G) == α * (β * G) – это то, что происходит в протоколе с красками. То есть, сторона A получает результат смешивания (β * G) и замешивает свою краску α: α * (β * G). Сторона B – наоборот. Казалось бы, должно выполняться (α * β) == (β * α), тогда работает схема. Именно так устроено в классическом DH, но с показателями степенй: (G^β)^α == (G^α)^β. Однако для протокола на красках, вообще говоря, (α * β) == (β * α) хоть и очевидно работает в “локальном” случае, но не применимо в иллюстрируемой схеме – ведь ни у стороны A, ни у стороны B нет готового состава (α * β) – они не могут его приготовить по условию “неразделимости” красок. Вариант (α * β) * G провернуть не получится, по условиям задачи: краски – это не натуральные числа. Поэтому-то “коммутативность” тут – это не настоящая коммутативность (без кавычек). Требуется именно “одинаковость” действия и краски α, и краски β на уже смешанные и подходящие краски. Это можно переписать в других обозначениях: A := α * G (подмешали α в G); B := β * G (подмешали β в G); α * B == β * A – потребовали выполнения базового свойства, необходимого для работы протокола DH на красках: β переводит A в тот же цвет, в который α переводит B.

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

Дело не только в химии: именно обобщение структурной особенности, которая переводит две разных “краски” строго в одну при действии разными элементами (другими “красками”) как раз и позволяет максимально обобщить и сам протокол DH, переписав его в терминах того, что в математике называется “действием группы”. Это, впрочем, отдельная история.

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

Классический вариант DH требует возведения в степень. Показатель степени является секретным ключом. Чтобы атакующая сторона не могла перебрать все показатели за обозримое время, значение должно быть большим. Но как быть стороне протокола, вычисляющей открытый параметр при помощи того же возведения в степень? Последовательно умножать генератор столько же раз, сколько и атакующий – выглядит несколько абсурдно. Хорошо, что знание показателя степени позволяет использовать быстрые методы, построенные на возведении генератора в квадрат и домножении на генератор в “нечётных” случаях: например, чтобы возвести 2 в пятую степень нужно дважды возвести 2 в квадрат и домножить на 2 – (2^2)^2 * 2, это три умножения, а не четыре, как для 2*2*2*2*2. В красках этого нет, но для любого практического воплощения протокола DH данное свойство “удвоения со сложением” необходимо – иначе легитимные стороны протокола оказываются в том же положении, что и атакующая сторона.