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

Воскресное чтение манускриптов. Сегодня небольшая заметка, но вновь про “Арифметику” Диофанта. В одной из предыдущих записок по этой теме упоминается редакторская правка на манускрипте 13 века Vat.gr.191 с “Арифметикой”. А именно – см. скриншот ниже.

Здесь справа вычеркунт фрагмент [μονάδ], а слева, на поле, дано исправление: ὁ ἄρα μείζων ἔσται ἀριθμοῦ α̅ M̊ μ̅ (“…тогда большее есть X + 40”).

Резонно ожидать, что на других манускриптах с “Арифметикой” это исправление внесено в основной текст. Для проверки возьмём манускрипт 16 века Reg.gr.128 всё из той же Ватиканской Апостольской библиотеки. Текст первой задачи находится тут в самом начале, на 3r. Вот скриншот соответствующего фрагмента страницы:

А вот текст, который на Vat.gr.191 указан на поле:

Фрагмент крупнее, на котором можно прочитать все те же буквы, что и на варианте 13 века, но в основном тексте:

Узнать легко, если обратить внимание на “монады”, которые обозначены Μ̊ в конце строки.

Так что, по крайней мере для одного более позднего манускрипта, – сходится.

Сейчас модная тема – влияние AI/ИИ на математику. Из-за того, что эта тема очень хорошо “прогрета” хайпом, раздуваемым вокруг ИИ/AI в прессе широкого назначения, она уже стала довольно сильна и внутри математического сообщества. Недавний пример раздувания – публикация OpenAI решений очередных “важных задач” силами LLM-систем. Чуть более ранний пример “внутренней реакции” – The Leiden Declaration.

Тут, естественно, основной момент в том, что коммерческие компании начали активно использовать реально специальные математические задачи в качестве марекетингового хода. Такой грубый перелом социальной страты нравится далеко не всем. Мнения, в стиле “что же теперь нам всем делать”, есть разные. Иногда интересные. Вот, например, в свежей статье The Crisis of AI-generated Mathematics (Max Weinreich, препринт), в качестве ответа на публикации, генерируемые LLM, фактически, предлагается внедрение на стороне журналов нового процесса, который приведёт к построению “обратной капчи”. Такая “обратная капча” нужна для доказательства того, что кто-то, – то есть, “человеческий математик”, – претендующий на “владение темой статьи”, действительно хорошо разобрался в этой теме. Цитата (перевод с английского):

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

Ключевые слова тут – “социальной” и “человеческой”.

Кстати, я не так давно писал про тавтологические капчи. Это концептуально похожая идея.

В Cloudflare на днях обновили свой сервис мониторинга логов Certificate Transparency (CT). Мониторинг отслеживает публикацию в логах (пре)сертификатов для заданного доменного имени. Напомню, что в прошлом году ни наличие сервиса мониторинга, ни наличие собственных логов CT, не помогли Cloudflare в течение нескольких месяцев выявить неавторизованный выпуск TLS-сертификатов для собственного же сервиса 1.1.1.1 (один из самых известных сервисов Cloudflare). Возможно, какие-то выводы были сделаны. Однако в этом контексте текущее обновление сервиса мониторинга CT выглядит ещё более странным. Дело в том, что это обновление отключает вывод оповещений о сертификтах, выпущенных системами Cloudflare. И делает это при помощи фильтра по открытым ключам.

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

Различать предлагается не сертификаты, а ключи. Так что сервис мониторинга CT больше не будет присылать уведомления об обнаружении в CT-логах серверных сертификатов, если эти сертификаты содержат тот же открытый ключ, который был сгенерирован Cloudflare для использования на TLS-прокси в сервисе веб-фронтэнда. И это весьма важный момент. Который, тем не менее, в сообщении Cloudflare освещается как-то однобоко. Да, по открытым ключам различать сертификаты удобнее, чем по отпечаткам полного сертификата. Я и сам так рекомендую делать, это здравый подход. Когда применяется правильно. Но нельзя забывать, что для выпуска сертификата Удостоверяющему Центру (УЦ) не нужен секретный ключ, соответствующий открытому ключу клиента.

То есть, то, что Cloudflare отслеживает и фильтрует сертификаты по ключу, не означает, что отслеживаются только сертификаты, выпущенные по запросу систем Cloudflare. Это совсем разные вещи, но про это Cloudflare не сообщает. Поскольку выпуск сертификата не требует секретного ключа, то, технически, какой угодно УЦ может выпустить сертификат для того же серверного открытого ключа, что использует и Cloudflare. Однако мониторинг CT, если верить описанию, этот сертификат не покажет. Проверка подписи в CSR и пр. – это, да, это всё привычные шаги, но, ещё раз, технически они никак на выпуск сертификата не влияют.

Конечно, такой выпуск сертификата для произвольного ключа – возможность весьма теоретическая, не поспорить: да, для выпуска секретный ключ не нужен, но, как минимум, чтобы использовать подобный “подменный” сертификат – тут секретный ключ уже потребуется. Это, однако, не отменяет странной подмены понятий: совпадающий открытый ключ – вообще никак не означает, что сертификат был выпущен по запросу систем Cloudflare, утверждать такое – ошибка.

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

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

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

В общем, получилась подмена базовой концепции. Формулировка базового вопроса, стоящего за подобным мониторингом CT, такая: разрешил ли администратор имени выпуск этого конкретного сертификта? Но, получается, что её “незаметно” подменили на другую: узнаёт ли сервис Cloudflare данный открытый ключ из сертификата? Почувствуйте, как говорится, разницу.

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

Недавно вышел документ RFC 10024 (обратите внимание: нумерация перевалила за десять тысяч). Этот RFC вводит идентификаторы для гибридов криптосистем обмена ключами в TLS 1.3. Это гибриды из классических и посквантовых криптосистем. В роли классических – выступают X25519 и ECDH, а в роли единственной постквантовой – ML-KEM. То есть, формально закрепляются следующие сочетания: X25519 + ML-KEM-768 как X25519MLKEM768 (0x11EC), ECDH/P-256 + ML-KEM-768 как SecP256r1MLKEM768 (0x11EB), и ECDH/P-384 + ML-KEM-1024 как SecP384r1MLKEM1024 (0x11ED).

При этом в качестве рекомендуемого (recommended) набора отмечен только X25519MLKEM768, варианты с ECDH – содержат значение N в поле “Recommended”. (Тут нужно оговорить, что флаг Recommended – это штука, назначаемая внутри IANA/IETF, и имеющая особенную трактовку; как минимум, тот факт, что ML-KEM стандартизована NIST, не означает, что IANA/IETF автоматически поставят флаг “рекомендуется”, тем более, что тут речь о гибридах; но и делать вывод, что нельзя использовать системы, у которых “Recommended: N” – тоже неверно: тогда бы и смысла в подобных RFC не было бы.)

Что здесь означают числа? В X25519 – это 2^255 – 19, модуль, задающий максимальную разрядность для этой криптосистемы; X25519 – массово используемый вариант протокола Диффи-Хеллмана (DH) на эллиптической кривой. P-256 и P-384 – две разных эллиптических кривых (отличных от используемой в 25519), на которых работает “типовой” протокол DH. P-256, которую также называют SecP256r1, имеет разрядность 256 бит, а P-384 (SecP384r1) – 384 бита. Математически, реализации DH на P-256 и P-384 – абсолютно идентичные, разные только кривые, а DH в версии X25519 тут в некоторых математических деталях отличается (распростраено мнение, – в том числе, среди специалистов, – что как раз эти отличия и делают реализации X25519, в целом, надёжнее и более стойкими, чем для DH на P-256/P-384).

ML-KEM тут фигурирует с двумя наборами параметров: 768 и 1024. Оценка стойкости ML-KEM – штука совсем сложная, поэтому тут только отмечу, что, несмотря на такие значение, ни 768, ни 1024 – как-то “линейно” с битовой стойкостью или эффективной разрядностью не связаны, но 1024, согласно спецификации, считается более стойким набором параметров. Поэтому для более стойкой кривой P-384 и выбран более стойкий вариант ML-KEM-1024.

Я не тестовом сервере tls13.1d.pw давно поддерживаю X25519MLKEM768 и SecP256r1MLKEM768, а вот P-384 пока не добавил.

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

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

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

Забавно, что в описании такая “замена слов” называется заменой на “лигатуру”, но, естественно, это не лигатура никакая: конечно, лигатура может соответствовать короткому слову, но не наоборот – произвольное слово не может стать лигатурой, чтобы “помешать боту”, потому что лигатура – это про буквы. И ещё более забавно, что, если верить репозиторию с кодом проекта на Github, в разработке использовалась LLM-система Claude.

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

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

Ну, идея довольно очевидная, поэтому, кто бы сомневался, что именно так и вышло: на днях OpenAI опубликовали список из десяти достаточно известных математических проблем, к которым предложены решения или контрпримеры, найденные “методами ИИ”, с использованием Lean.

Интересно, что одна из решённых в OpenAI задач – прямо указана и в “Коуровской тетради”, но лишь в самой свежей, 21-й редакции (я проверил только для англоязычной версии, понятно). В публикации OpenAI – это третья глава с утверждением non-sofic groups exist и контрпримером – с построением такой группы. В англоязычной “Коуровской тетради” это задача 21.86. Да, там обратная формулировка: “всякая ли группа является софической (sofic)?”. Но это как раз то, что нужно для поиска контрпримера: покажите одну группу, которая non-sofic, и это даст ответ – нет, не всякая. (“Софической”, конечно, не лучший перевод – должно быть “терминальной” или “терминируемой”, но данный вариант уже занят.)

Но что особенно занятно, так это то, что решённая ИИ OpenAI задача 21.86 в тетрадь добавлена в этом же, 2026 году! Удивительное совпадение. Например, препринт на Arxiv с 21-м изданием, в котором появляется данная задача, датирован январём 2026 года (версия 39, кому интересно). Естественно, сама исходная гипотеза про “софичность” всех групп – сильно старше, она, примерно, 2000 года. Однако в более старых версиях “Коуровской тетради” она не указана, а, похоже, появляется только в 2026 году.

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

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

1. В ОС на гипервизоре не оказалось нужной уязвимости, для эксплуатирования которой требуется отправка сетевых пакетов. Ну, то есть, не за что зацепиться. А вот в ОС, исполняемой в виртуальной машине, уязвимость есть. Если пакет не добрался до виртуальной машины, то пакет не повредил ни машине, ни гипервизору. Это, пожалуй, самая простая, банальная причина применять фильтры на уровень выше, чем находятся внутренние интерфейсы VM.

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

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

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

Это, естественно, далеко не все причины. Например, тут вообще не затронуты обратные сигналы (то есть, пакеты, отправляемые из гостевых систем) и взаимодействие между VM, когда из одной можно перепрыгнуть в другую, соседнюю.

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

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

Вообще, с подобными, – но невидимыми, – метками интересен совсем другой аспект: грамотно сконструированные метки позволят определять не просто LLM-источник, но конкретное происхождение текста (не только текста, понятно: то же применимо и к картинкам, и к видеофайлам). Это даёт мощный механизм влияния. Я писал об этом в 2024 году:

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

Несколько месяцев назад, в конце марта 2026 года, я публиковал на dxdt.blog ссылку на занятную языковую задачку из газеты The Guardian. В задаче нужно было сопоставить последовательности разноцветных прямоугольников фразам на английском языке. Цитата:

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

Тогда я попробовал эту задачу задать ChatGPT (естественно, после того, как решил все фразы сам, чтобы было с чем сравнивать), но LLM не смогла угадать ни одной фразы.

Решил вот на днях повторно эту же задачу проверить. Что ж, то ли потому, что развитие LLM идёт очень быстро, то ли потому, что к исходной задаче опубликовали ответы и эти ответы стали доступны для включения в базу LLM, но теперь задачу отлично и без ошибок решили и ChatGPT (уже GPT-5.6 Pro), и Claude (уже Opus 5 Max).

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

Естественно, обе ИИ/LLM-системы верно отметили цитаты из Шекспира (Claude с гиперссылками на исходные тексты даже, но это, скорее всего, связано с настройками конкретного аккаунта), и указали на использованную оригинальную запись: glisters в “All that glisters is not gold” (сейчас, скорее всего, написали бы glitters, но это неверно).

Так что какое-то развитие, очевидно, есть. Только данный пример не показывает, что это качественное развитие: решения подобной задачи я ожидал и в начале этого года.

Появилась новая публикация (Daniel R. Simon), предлагающая квантовый алгоритм, взламывающий – теоретически! – криптосистемы типа ML-KEM/ML-DSA за полиномиальное время (то есть, атака предложена на задачу, лежащую в основе предположения о стойкости, в том числе, ML-KEM/ML-DSA, но подходит не только для них). Для работы алгоритма потребуется подходящий квантовый компьютер – уже этим многое сказано. Однако пока что и сама работа опубликована в статусе черновика, о чём там прямо сказано. То есть, скорее всего, – найдутся ошибки.

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

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

Что будет означать появление описания квантового алгоритма, эффективно взламывающего ML-KEM/ML-DSA и другие криптосистемы под собирательным обозначением “на решётках”? Это точно не приблизит к реальности сами универсальные квантовые компьютеры, но зато создаст вполне себе хорошее обоснование для того, чтобы либо улучшать стойкость ML-KEM/ML-DSA и прочих “решёточных” криптосистем, либо переходить на другие криптосистемы. И это будет весьма забавно: для атаки на постквантовые криптосистемы предложены новые теоретические квантовые алгоритмы, поэтому нужны суперпостквантовые криптосистемы, устойчивые и к алгоритму Шора, и к новому алгоритму “Имярек”.

Посмотрим, в общем, что там предложат. Так или иначе, но считать ML-KEM/ML-DSA неприступными – точно ещё рано.

(Update, 17/08/2026: в свежей работе (Aparna Gupte, Seyoon Ragavan, Mark Zhandry) утверждается, что квантовые алгоритмы данного типа, – как предложенный в исходной публикации, – вообще не позволяют извлечь информацию в количестве, необходимом для взлома криптосистемы.)

Тем временем, для игры Quake продолжают выходить дополнения и новые уровни, в том числе, вполне официальные (ну, с учётом административных пертурбаций, приключившихся за тридцать прошедших лет): юбилейное дополнение называется Dawn of the Machine. За Quake, конечно, необходмо записать заметное историческое влияние на мир компьютерных игр, но, всё же, по данному показателю – это далеко не Doom.