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

В Let’s Encrypt собираются внедрить (англ.) новый метод проверки права управления доменом (DCV), который, при помощи публикации специальной TXT-записи, привязывает DNS-зону к ACME-аккаунту, а не к коду валидации, и при этом такая привязка становится “постоянной” – видимо, с точностью до того, как сервер будет запрашивать TXT-записи и фиксировать факт удаления соответствующего кода. Метод называется DNS-PERSIST-01.

Довольно занятное начинание. Например, в описании от Let’s Encrypt (по ссылке выше) имеется пространная “мотивировочная часть”, где несколько раз утверждается, что, мол, “во многих конфигурациях реквизиты доступа к DNS API распределяются через “пайплайны” выпуска и обновления [сертификатов], увеличивая количество мест, в которых атакующий может их [реквизиты] скомпрометировать”. Так, конечно, делать нельзя – нельзя раздавать реквизиты доступа к DNS “пайплайнами” по многим местам – ACME этого не требует. Но забавный момент тут в другом: предлагаемая схема, предположим, уходит от “раздачи реквизитов” от DNS, но зато привязывает всю защиту и безопасность к ключу от ACME-аккаунта!

То есть, ACME-аккаунт в этой схеме строго привязывается к DNS-имени, поэтому, если атакующая сторона получила доступ к ACME-аккаунту, то доступ к DNS уже вообще не нужен. Многие ли DevOps и системные администраторы вообще знают, что в ACME-клиенте есть секретный ключ от аккаунта, которым подписываются запросы, и о том, где этот ключ хранится? Не раздаётся ли этот ключ через “пайплайны” по резервным копиям? Вопросы, впрочем, риторические. Но должно же быть очевидно, что замена одной потенциальной “точки взлома” (доступы к DNS) на единственную другую (ACME-ключ клиента) – не даёт каких-то новых преимуществ с точки зрения безопасности. Но нет – приводят в пример. (Все эти моменты, кстати, описаны в черновике RFC для DNS-PERSIST-01. Но это – и черновик, и вряд ли многие прочитают.)

ACME-аккаунт – контролируется УЦ; можно предположить, что это не важно – УЦ и так выпускает какие хочет сертификаты; однако на практике, если используется одноразовый код подтверждения через DNS, есть небольшая надежда, что модуль проверки права управления доменом – как-то отвязан от модуля авторизации ACME-запросов; в случае же нового варианта – достаточно контроля над обработкой ACME-запросов.

И если, на практике, на стороне, которая заказывает TLS-сертификаты, управление DNS ещё как-то понятно администраторам, то ACME-клиент – совсем мутная вода.

Естественно, для того, чтобы публиковать коды ACME-подтверждения в DNS, не требуется раздавать реквизиты от этой DNS по куче мест. То есть, понятно, что такое регулярно происходит на практике, тут у Let’s Encrypt всё верно написано: это, как раз, один из побочных эффектов всей этой “автоматической истории” с ACME – раскидывание CNAME и тому подобные нехорошие варианты. Но управление DNS проще реализовать правильно и надёжно, чем управление ACME-клиентом: например, машина, которая является источником обновлений DNS-зоны, может сама ходить за кодами на точку раздачи, подтверждая потом публикацию ACME-клиенту, и так далее – вариантов много. В теории, наверное, и для ACME-ключа можно придумать серьёзную защиту. Проблема тут совсем в другом: многие знают, что DNS нужно защищать, а то будут проблемы; о том, что защищать нужно ACME-аккаунт – ну, может, кто-то и подумал, но даже если и подумал, то, скорее всего, решил: “а зачем? всё равно же DNS-доступ нужен для выпуска сертификата”. И не забывайте, что доступ к DNS, действительно, всё так же позволяет выпустить TLS-сертификат, только теперь ещё и доступа только к ACME-аккаунту становится достаточно.

Кстати, про схемы генерирования криптографических параметров и при чём здесь NUMS (Nothing Up My Sleeve – “Ничего в моём рукаве”). Опасения всегда связаны вот с чем: предположим, что сильный атакующий разработал специальные “секретные теоремы высшей алгебры” и, например, может эффективно взламывать асимметричные криптосистемы для чисел специального вида, но какой там “вид” – это секрет. Те, кто “секретные теоремы” ещё не узнал, взламывать не могут. Но чтобы схема работала, стандартные параметры должны состоять из тех самых чисел специального вида. (Конечно, схема имеет фундаментальную проблему: как только “секретные теоремы” перстают быть “секретными” – криптосистема ломается для всех. С одной стороны – это очень плохо. С другой стороны – сейчас уже обстановка достаточно странная для того, чтобы подумать: “кому какая разница? просто возьмите другую криптосистему”.)

Использование специальных параметров, если они подобраны хорошо и в соответствии с математикой криптосистемы, – это не обязательно бэкдор в самой криптосистеме, как ни странно. Дело в том, что и так есть много требований к выбору параметров, чтобы эти параметры были стойкими. Например, в “мультипликативном” варианте протокола Диффи-Хеллмана модуль P должен быть простым числом, но таким, что (P-1)/2 – тоже простое число. Или, для классических схем на эллиптических кривых, с дискретным логарифмом, нельзя выбирать кривые определённого вида, например, суперсингулярные с малой степенью вложения. И так далее, и тому подобное: есть много требований к RSA, есть требования к ML-DSA и пр. Начать с того, что элементарное требование на минимальную битовую длину записи – это требование к стойкости числового параметра, которое является универсальным и для симметричных, и для асимметричных криптосистем. Другими словами – у конкретных реализаций криптосистем есть типовые параметры, эти параметры должны быть выбраны так, чтобы не было “сомнений в добрых намерениях”. “Специальный” же вид – лишь добавляет “секретное” свойство, которое прямо в требованиях не указано.

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

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

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

Во-первых, в полученных таким способом числах есть дополнительная структура. Это важный момент: нельзя говорить, что это числа, в которых дополнительной структуры быть не может. Структура там есть, и она как раз состоит в том, что часть битов двоичной записи соответствует цифрам записи числа e с определённой позиции, согласно опубликованной формуле. В этом и смысл: конечно, e – иррациональное, а в его бесконечной записи можно найти запись любого простого числа (возможно, потребуется подобрать систему счисления, но это совсем технические детали, оставим их); однако формула выбора гарантирует, что будет взято первое слева подходящее число. Это число вполне конкретное, предопределённое. Его нельзя заранее подогнать под требования закладки. Да, данное число определяется структурой, но эту структуру заложили давно, когда определяли математическую константу e. Сложно предположить, что Бернулли и Эйлер придумали алгоритмы вычисления e с учётом непростых криптографических реалий начала 21 века.

Во-вторых, имеющаяся публичная структура (см. формулу с e) гарантирует, – в какой-то мере, конечно, – что число нельзя снабдить другой, скрытой произвольной структурой. Естественно, строго гарантировать тут можно то, что выдача алгоритма вычисления e не была приспособлена под требования закладки, но не обратное – требования закладки, всё же, можно приспособить под запись константы e. То есть, такую вторичную структуру нужно будет согласовать с уже имеющимся алгоритмом. Это, скорее всего, возможно проделать, но всё равно – какая-то фантастика. Если уж допускать такие возможности по созданию закладок в параметрах, то что тогда вообще помешает реализовать закладку любым другим теоретическим способом?

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

Колонка Дмитрия Буркова про реальные принципы построения NAT (это преобразование адресов, массово используемое сейчас для доступа к глобальной Сети), цитата:

По сути, NAT — это не столько про адреса, сколько про трансляцию идентификаторов между разными доменами управления. Адрес в этом смысле — всего лишь удобный носитель.

Рекомендую почитать. Потому что, действительно, о том, какая именно логика соответствует NAT, постоянно забывают.

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

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

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

А компилятор для подмножества C, – с куда меньшими оговорками, чем в случае ИИ/LLM выше, – можно уложить в 512 байтов, если что. И даже без Rust. Вот только с хайпом в СМИ на этом направлении будет сложновато.

Корень глобальной DNS сейчас подписан, в рамках DNSSEC, криптосистемой RSA. В ICANN – организации, определяющей требования к работе глобальной DNS, – некоторое время назад запустили процесс перехода корневой зоны с RSA на ECDSA (P-256/SHA-256, это алгоритм номер 13 в DNSSEC). В текущей версии предложения ICANN планируется переход в течение четырёх лет. То есть, переход должен завершиться в 2030 году (традиционная дата, да).

Сейчас среди зон ниже первого уровня мало что подписано, мало где есть DNSSEC. Например, в .RU – это какие-то доли процента. Тем не менее, DNSSEC касается всех валидирующих резолверов, и если DNSSEC сломается, то сломается всё дерево ниже подписанной точки, в которой DNSSEC отвалилась. Например, так как подписана сама зона .RU, то когда в .RU сломались подписи DNSSEC, отвалились абсолютно все домены второго (и ниже) уровня внутри .RU, вне зависимости от того, есть в каком-то из этих доменов DNSSEC или нет. Ещё раз подчеркну, это касается только валидирующих резолверов, однако сейчас самые массовые публичные резолверы (Google Public DNS, Cloudflare и др.) – валидирующие. Да и вообще – в 20-х годах 21 века нужно использовать только валидирующий резолвер. Соответственно, если отвалится DNSSEC в корневой зоне – DNS сломается, фактически, для всего Интернета.

DNSSEC в корне DNS полностью внедрили в 2010 году, естественно, на RSA. Так как при вводе DNSSEC в эксплуатацию никто не озаботился тем, чтобы не только согласовать процесс ротации корневого ключа, но и хотя бы предусмотреть такой процесс, замена корневого ключа состоялась только в 2018 году. Впрочем, вряд ли это как-то повлияло на практическую стойкость: практические возможности по взлому RSA-ключей из подписей – сильно расходятся с теоретическими предположениями. А тем более эффект сомнителен, если учитывать реальность использования DNS и DNSSEC и схему подписывания самой корневой зоны. Для подписи зоны используются дополнительные ключи, которые, в свою очередь, удостоверяются корневым. Процесс генерирования новых ключей подписи зоны и удостоверения этих ключей изначально предполагал серьёзные шаги по обеспечению безопасности криптографических данных: защищённые помещения, доверенные люди, физические сейфы, физические ключи, аппаратные модули (HSM) и так далее.

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

И всё же, вернёмся к ключам DNSSEC. Cледующая ротация корневого ключа намечена на октябрь 2026, но это опять будет RSA. Потому что, как нетрудно догадаться, механизма замены криптосистемы в корне DNS тоже не предусмотрели. Механизм разрабатывают сейчас.

Самое занятное, что в рамках перехода на ECDSA имеющиеся ключи RSA собираются сократить. Да. Собираются уменьшить их разрядность с 2048 бит до 1536 бит. Как бы, по нынешним временам, 1536 бит не считаются стойким вариантом. (Заметьте, впрочем, что для атаки на гипотетическом-фантастическом квантовом компьютере – 1536 битов RSA всё равно сильнее, чем 256 бит ECDSA, потому что теоретические алгоритмы квантового взлома прямо оперируют разрядностью, и для записи 256 бит может потребоваться меньше кубитов.) Естественно, снижение разрядности RSA обусловлено стремлением удерживать максимальный размер DNS-ответа ниже границы, доступной в UDP-транспорте: ниже 1232 байтов. Это позволяет избежать перехода на TCP со стороны резолверов. (DNS требует перехода на TCP в тех случаях, когда ответы не проходят по размеру в UDP.)

Согласно плану, уменьшение длины RSA-ключа в корне DNS намечено на 2027 год. А в первой четверти 2028 года запланирована публикация ECDSA-подписей. При этом, сами ECDSA-ключи в зоне публиковать сразу не собираются. Тоже занятное решение, обусловленное, скорее всего, тем, что DNSSEC требует подписывать зону всеми обозначенными криптосистемами, но не всеми ключами. Поэтому ключи опубликуют позже, во второй четверти 2027 года, когда ECDSA-подписи уже побывают в зоне. RSA-ключи отзовут в 2030. Если по плану. Потому что документ предварительный и пока что выставлен для публичного обсуждения.

Программный код, генерируемый при помощи LLM, и автоматическое применение средств анализа кода (но не тех, которые уже есть в LLM-сервисе) – принесут забавные результаты. А главное – массовые. О чём тут речь: например, если у вас внедрено что-то типа “безопасной разработки ПО”, то использование, как минимум, статического анализатора кода – оказывается обязательным; кроме того, понятно, есть ещё автоматические тесты разных типов.

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

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

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

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

И это кроме того, что сервис LLM ещё и объединяет весь код в общую “базу” для всех пользователей: на результаты разработки компании “Имярек А” влияют тесты компании “Имярек Б”, которые компании друг о друге не знают, но используют один и тот же новомодный ИИ/LLM-сервис.

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

Идея, что WhatsApp может выборочно и задним числом получать доступ к содержанию [зашифрованных в режиме “точка-точка”] индивидуальных чатов, представляет собой математическую невозможность. (Оригинал: “idea that WhatsApp can selectively and retroactively access the content of [end-to-end encrypted] individual chats is a mathematical impossibility”).

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

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

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

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

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

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

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

При вычислении значения цифровой подписи 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), которые отнимают очень много ресурсов разработчиков, но не несут с собой ничего полезного для проекта.