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

Кстати, о языках программирования из моей практики. В прошлом, 2025, году, как обычно, я довольно много использовал Go. Наверное, этот язык – на первом месте у меня, “по распространённости”.

Необычно много, – ну, по моим меркам и нынешним временам, – было C/C++. Но, в основном, это микроконтроллеры PIC и AVR. Хотя, одна старая утилита для x86, написанная на C, тоже попалась.

Заметный объём JavaScript – тут нечего добавить. Shell-скрипты – да, регулярно нужен Bash.

Как обычно, регулярно использовал Python, но, так сказать, ситуативно – лишь потому, что это входной язык Sage, системы компьютерной алгебры.

А вот ассемблеров за прошлый год попадалось меньше, чем обычно. И, опять же, почти всегда – для микроконтроллеров.

Ещё написал за прошлый год несколько сиюминутных Perl-скриптов для обработки данных, но там-то, всего, может, три сотни строк в сумме.

И иногда попадался Rust. Ну, как попадался: иногда приходится читать код, а кроме того, например, написал я на Rust микроскопический пример для статьи про сложение точек эллиптической кривой на “Хабр”.

Разнообразие, получается, не слишком велико.

В 2023 году я писал, что замена нормальных процессов разработки программного обеспечения на генерирование кода силами ИИ/LLM может привести к получению “транслятора тестовых примеров” вместо реализации шифра. Цитата:

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

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

Оказалось, что этот код сгенерирован ИИ/LLM, содержит грубейшие ошибки и, что главное, не реализует целый пласт необходимых функций. То есть, это не Matrix-сервер.

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

   // For now, store the seed as both public and private (placeholder) 
   // In production, use proper Ed25519 implementation 
   const publicKey = btoa(String.fromCharCode(...seed.slice(0, 32))); 
   const privateKey = btoa(String.fromCharCode(...seed)); 

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

   // Canonical JSON representation 
   const canonical = canonicalJson(obj); 
   const hash = await sha256(canonical); 
  
   // Placeholder signature - in production use Ed25519 
   const signature = hash;

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

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

В Quanta Magazine статья, рассуждающая о том, не закончилась ли “физика частиц” с открытием бозона Хиггса при помощи LHC. Ну, там, в заголовке, как бы, сразу заложены варианты, однако основной вывод сводится к тому, что, мол, – да, закончилась.

Тут особенно содержательно что-то сказать сложно, работы физиков стали непонятными. Однако со стороны, – при всём уважении, – действительно, давно уже выглядит как непрекращающиеся попытки уточнения десятичных знаков в записи числа Пи по результатам мысленных экспериментов. Но в статье есть более интересные моменты, а именно – занятные отсылки к ИИ/LLM. Например, цитата про современный LHC:

In the last couple of years, data handling at the collider has improved with the use of AI. Pattern recognizers can sort through the outgoing debris of proton collisions and classify collision events more accurately than human-made algorithms can.
(Последние пару лет обработка данных коллайдера улучшилась благодаря использованию ИИ. “Обнаружители” паттернов способны просеивать разбегающиеся осколки от столкновений протонов и классифицировать события более точно, чем сделанные (разработанные) человеком алгоритмы.)

От хайпа нигде не скрыться: “более точно, чем сделанные человеком алгоритмы” – можно подумать, что алгоритмы этих “обнаружителей/распознавателей” (recognizers) – созданы не людьми. Хотя… есть же прекрасная литературная теория, что все эти попытки постройки всё более мощных ускорителей частиц – это скрытое воздействие неких внешних сил, огромный космический флот которых уже стоит в варпе рядом с Землей, но не может осуществить финальное вторжение, потому что для прорыва в реальное пространство из варпа нужен портал. Вот этот портал и должны построить под прикрытием создания ускорителя, а инструкции передаются в виде малых межпространственных ментальных воздействий на неокрепшие умы (как говорится: “An open mind is like a fortress with its gates unbarred and unguarded”, или, в дословном переводе: “открытый разум – подобен крепости, ворота которой не заперты и не охраняются”). Так что, да, может, это и не люди придумали алгоритмы ИИ для LHC. Шутка. А в статье, наверное, серьёзно так написано.

Есть и ещё одна занятная цитата – прогноз, который даёт Джаред Каплан (Jared Kaplan) из Anthropic (это, как раз, одна из ведущих компаний в области продвижения ИИ/LLM):

I would give like a 50% chance that in two or three years, theoretical physicists will mostly be replaced with AI. Brilliant people like Nima Arkani-Hamed or Ed Witten, AI will be generating papers that are as good as their papers pretty autonomously.
(Я бы дал шанс процентов 50, что через два или три года физики-теоретики будут в основном заменены ИИ. Такие выдающиеся люди, Нима Аркани-Хамед или Эд Виттен, – ИИ будет генерировать статьи, столь же хорошие, как и их статьи, совершенно автономно.)

“ИИ будет генерировать (generate) статьи” – кто бы, как говорится, сомневался. Не совсем понятно, насколько это лестная оценка качества статей, но да ладно. Шансы, впрочем, не так велики – 50% всего-то. Но через два года. Посмотрим.

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

Нередко приходится слышать и читать, что в ECDSA значение “параметра k” должно вырабатываться криптографически стойким генератором (псевдо)случайных чисел, для каждой операции подписи. Например, так написано в английской “Википедии”, и практически то же самое написано в стандарте FIPS 186 (но обратите внимание, что в современном стандарте уже есть и другой вариант). Нельзя сказать, что это уж совсем неверно, но есть занятные тонкости с трактовкой слова “должно”.

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

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

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

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

Кстати, всё это непосредственно применимо и к современной ГОСТ-подписи: там есть такой же “параметр k”, точно так же влияющий на выдачу криптосистемы подписи и на стойкость реализации.

Сurl отказывается от программы вознаграждений за найденные уязвимости (bug bounty), которая несколько лет работала на базе Hackerone. Основная причина: затапливание “ИИ-помоями” (ложными и абсурдными сообщениями об уязвимостях, сгенерированными ИИ/LLM), которые отнимают очень много ресурсов разработчиков, но не несут с собой ничего полезного для проекта.

Ферма сформулировал самую знаменитую теорему имени Ферма на полях одного из изданий “Арифметики” Диофанта. Труды Диофанта сейчас доступны и в более древних вариантах, чем тот, которым пользовался Ферма. Но, понятно, всё в электронном виде. Однако это позволяет очередной раз взглянуть на древнюю математическую нотацию, чтобы оценить разрыв с нотацией современной.

Воскресное чтение манускриптов. Cегодня – совсем небольшой фрагмент “Арифметики” Диофанта в версии манускрипта 13 века н.э. Vat.gr.191 из коллекции Ватиканской Апостольской библиотеки. Диофант Александрийский, как считается, работал в третьем веке нашей эры, то есть, примерно, за десять веков до написания данного манускрипта. В этом фрагменте (лист 360r) Диофант определяет свою нотацию для записи степеней неизвестной – квадрата, куба и так далее – см. скриншот.

В выделенном фрагменте Диофант пишет (перевод – максимально близко к тексту): “Соответственно, тогда каждое из тех чисел, сокращённое обозначение получив, элементом арифметической теории становится; назовём же теперь квадратную степень, и да станет она обозначаться [буквой] Δ, имеющей сверху Γ, [Δ^γ] степень”.

Дельта здесь – это первая буква δύναμις. На данном манускрипте, как раз, написано с ошибкой – указана строчная буква δ. Почему δύναμις? Это как в русском “динамо-” – “сила, мощь”, но в значении английского power. То есть, это именно степень, но вторая – квадрат.

Дальше идёт третья степень: “Дальше – куб, и с [буквой] Κ, имеющей сверху Γ, Κ^γ – куб”. Каппа здесь, конечно, от κύβος, “кубос” или куб.

Дальнейший текст на скриншоте не выделен, но, на базе этих двух обозначений, для квадрата и куба, Диофант далее систематически строит “составные” степени, вплоть до шестой. Например, Δ^γΔ – “дельта-дельта” или, если хотите буквально, “динамодинамис” – δυναμοδύναμις (середина нижней строки на скриншоте, если хотите прочитать исходник). Δ^γΔ, это, конечно, четвертая степень – потому что “квадрат квадрата”.

На полях данного манускрипта тоже есть заметки – схолии. Но это тема для другой записки.

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

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

Вот хороший пример: предложение (в контексте большего текста) “Хуже того, этот кто-то может заменить пакеты или изменить передаваемые в них данные” – ChatGPT 5 переводит так: “Worse still, an attacker can modify or replace those packets”. Оставим за скобками “an attacker”, которого тут нет в исходном тексте – это не страшно. Но здесь сохранено “worse still”, – калька с русского “хуже того”. На английском – “worse still” читается как весьма драматический заход. Куда сильнее, чем “хуже того”, даже посильнее, чем “хуже всего”. Могло бы быть что-то вроде “in fact” или “moreover”. Самое забавное, что ChatGPT об этом, как бы, “знает”. Вот эти два варианта, – “in fact”, “moreover” – предложило само ChatGPT, когда я указал, что “worse still” – плохой “loan translation” (“прямое заимствование”, калька). То есть, система “знает” верные слова, но не может их выставить. Всё из-за того, что это синонимайзер, к сожалению. И “совпides” тому примером.

Но как подстрочник – вполне неплохо, факт. Продолжаем наблюдать.

Авторская колонка Дмитрия Буркова – о том, един ли всё ещё корень глобальной DNS. Цитата:

Начиная с 1990-х годов возникали, существовали и исчезали проекты вроде AlterNIC, OpenNIC и Yeti DNS, стремившиеся предложить децентрализованные, общественные или экспериментальные альтернативы.

Превращения слов. Систему Kubernetes на русском ИТ-жаргоне очень часто называют “Куб” или “Кубик”. Что, конечно, довольно забавно, потому что это дважды трансформированное из греческого через английский “фонетическое сокращение”. Дело в том, что исходное древнегреческое κυβερνήτης (“рулевой, кормчий, управляющий”) соответствует русскому “губернатор”. Так что должно быть не “куб” (которое, из-за “кубических мер”, много в каких жаргонах и арго фигурирует, но с другими значениями), а “губер”.

В DNS есть несколько штатных способов создать циклы, которые сделают обычный рекурсивный опрос невозможным. Самый привычный способ – использование субординатных NS. То есть, пусть зона example.com делегирована на два авторитативных NS – ns1.example.com, ns2.example.com. Оба имени находятся в исходной зоне example.com, откуда и название “субординатные”. Чтобы найти A-запись в зоне example.com – резолверу нужно опросить хотя бы один из авторитативных NS-ов, а чтобы опросить NS, нужно знать его IP-адрес (A- или AAAA-запись), а чтобы узнать IP-адрес – нужно опросить авторитативный NS зоны example.com, ну и так далее.

Если бы не glue-записи с IP-адресами, то разрешить такой цикл было бы невозможно. Glue-записи – это специальный способ предоставить резолверу IP-адреса узлов, которые, из-за циклов в адресации, невозможно найти обычным рекурсивным опросом. Эти записи передаются авторитативными серверами в специальной секции DNS-ответа и, в случае примера выше, сразу содержат IP-адреса для имён ns1.example.com, ns2.example.com. Без glue-записей практическая DNS работать не будет. И не только по причине наличия только что описанного элементарного цикла: есть случаи и посложнее.

Один из таких случаев – “кросс-делегирование”. Предположим, что зона example.net делегирована на ns1.example.com, ns2.example.com. Обратите внимание: из зоны .net – делегируется на имена в .com. При этом зона example.com – делегирована на ns1.example.net, ns2.example.net.

Теперь предположим, что резолвер ищет A-запись для example.com. Как резолвер мог бы действовать:

(0) для обнаружения нужной A-записи резолверу необходимо найти авторитативные серверы зоны example.com;

(1) на авторитативных серверах делегирующей зоны .com резолвер узнаёт, что NS для example.com – ns1.example.net, ns2.example.net;

(2) теперь резолвер должен определить A-записи для этих имён серверов (ns1.example.net, ns2.example.net);

(3) но для этого нужно найти авторитативные серверы зоны example.net;

(4) на серверах делегирующей зоны .net резолвер узнаёт, что имена этих серверов – ns1.example.com, ns2.example.com;

(5) теперь, чтобы узнать A-записи ns1.example.com, ns2.example.com, резолверу нужно определить авторитативные серверы зоны example.com, но это – шаг (1); получился цикл.

Естественно, настраивать так зоны, мягко говоря, не очень хорошо, даже несмотря на то, что данный цикл разрешается с использованием glue-записей. В случае использования glue-записей, их должна предоставлять каждая делегирующая зона, но в составе этих записей уже будут имена из другой зоны. То есть, в случае простого примера с субординатными NS для example.com – glue-записи содержат адреса серверов внутри example.com (ns1, ns2); в случае “кросс-делегирования” – адреса уже будут для имён в example.net.

Это далеко не все варианты создания циклов. Есть и ещё более сложное “петлевое” делегирование, и постоянно неверно используемая запись CNAME. Что касается CNAME, то это самая проблемная запись в DNS. CNAME предназначена для перезапуска процесса рекурсивного опроса. Вдумайтесь: в DNS изначально заложен сигнал, который, при штатном использовании, заставляет резолвер “начать заново”. Можно ли предложить лучшую основу для DoS? Вряд ли. Потому что если резолвер, отправив запрос про test.ru, получил CNAME с указанием на example.com, то он должен “забыть” исходное test.ru и начать опрос DNS для example.com. И так далее. CNAME можно указать для любого имени. Стоит ли говорить, что нетрудно построить цикл из нескольких CNAME? Нет, не стоит – это очевидно, а такой цикл может быть сколь угодно сложным.

Естественно, DNS-резолверы вынуждены отслеживать все эти особенности, чтобы не зависнуть.

Из серии “Кто бы сомневался!”: в Project Zero публикуют описание того, как, проэксплуатировав две уязвимости (CVE-2025-54957, CVE-2025-36934), им удалось выполнить на android-устройстве произвольный код с правами ядра ОС. Тут самое интересное не уязвимости, а то, что данную атаку на уровень 0-click (то есть, без участия пользователя) переводит наличие в смартфоне ИИ-агента, читающего входящие сообщения.

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

Вот поэтому попадает в серию “Кто бы сомневался!”. Как говорится: эти ИИ-агенты – они и эксплоиты будут вместо пользователя на его устройстве запускать. Максимальная автоматизация.

(Описание на OpenNET.)