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

Известная шутка гласит, что категорий людей – 10: одни уже знают двоичную систему счисления, а другие – ещё нет. Занятно, что 10₂ обозначает простое число – два. Это большая редкость в системах счисления, которые рутинно используются в ИТ. Понятно, что ни в восьмеричной, ни в десятичной, ни в шестнадцатеричной, 10 (как запись) не может обозначать простое число (как и всякая запись, заканчивающаяся на 0). А в двоичной – пожалуйста.

Естественно, это возможно только потому, что основание двоичной системы – простое число два. Если взять любое другое простое основание, то 10 тоже будет простым, потому что это и есть запись основания: три – по основанию 3, пять – по основанию 5, семь – 7, и так далее. Но наиболее привычны, кроме десятичной (десятеричной), это двоичная, восьмеричная и шестнадцатеричная.

Возьмём запись 11. В двоичной – это простое число три (11₂ = 2 + 1 = 3). В восьмеричной – девять, составное, но квадрат простого: 3^2. Та же запись 11 означает одиннадцать в десятичной, простое. Шестнадцатеричное 11 – это семнадцать, тоже простое.

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

Обратите внимание, что запись чисел словами – это инвариантная, относительно системы счисления, запись.

111₂ = семь (простое);
111₈ = семьдесят пять (составное);
111₁₀ = сто одиннадцать (простое);
111₁₆ = двести семьдесят три (составное: 3*7*D).

Не забывая о том, что все простые числа, кроме числа два и числа три, имеют вид 6*n +/- 1, на трёх цифрах можно и остановиться. Тем более, что шестеричная система счисления не является распространённой.

В продолжение записки о том, что появится новый тип УЦ (Удостоверяющих Центров) для выпуска TLS-сертификатов, базирующихся на хеш-деревьях (деревьях Меркла). Речь в этой заметке не про технические детали (про них, возможно, будет отдельно в другой заметке), а про изменение технологических и административных процессов в работе УЦ, которые с новым подходом связаны. Сейчас пока что всё существует в виде тестов и черновиков RFC, но можно ожидать быстрого перехода УЦ на описанную схему. Примерно так же, как было с внедрением обязательных SCT-меток (от логов Cetrificate Transparency) в сертификаты: браузеры начинают верить только в сертификаты с правильными SCT-метками – УЦ для веба вынуждены подстроиться.

Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог выпуска сертификатов, который лог становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.

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

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

Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.

И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).

Почему весь смысл в сертификатах без подписи? Потому что только такие сертификаты позволяют отказаться от больших подписей криптосистем с постквантовой стойкостью. В этом смысл оптимизации. Да, тут нетрудно заметить ещё один занятный момент: речь про ML-DSA, а там, действительно, подпись занимает несколько килобайтов; казалось бы, и квантовые компьютеры выглядят теоретическим построением, и никто не доказал, что большой размер подписи является необходимым условием постквантовой стойкости – тем не менее, именно многокилобайтные подписи оказываются существенным фактором внедрения сертификатов без подписи и новой схемы работы УЦ. Впрочем, необходимо отметить и то, что схема с хеш-деревьями позволяет существенно экономить трафик уже и для RSA-подписей (с разрядностью 4096 бит и больше).

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

Узел, запрашивающий выпуск нового сертификата у УЦ, может получить практически сразу же “полный сертификат” и, с некоторой задержкой, оптимизированный сертификат без подписей. Соответственно, TLS-сервер, при установлении TLS-соединения, мог бы выбирать, какой сертификат отправить клиенту, в зависимости от сигналов в начальном сообщении клиента. В TLS планируется добавить расширения, которые позволят информировать сервер о списке доверенных состояний деревьев (логов), которые известны клиенту. Так что, если сервер видит, что клиент не сможет валидировать оптимизированный сертификат (без подписей), то сервер присылает полный сертификат.

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

То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.

В Google планируют уже в следующем году начать строить в браузере новую инфраструктуру УЦ для TLS, используя схему с доказательствами на деревьях Меркла (хеш-деревьях) в оконечных сертификатах.

Это, технически, совсем другая история, по сравнению с действующими сейчас способами выпуска и публикации TLS-сертификатов. Доказательства принадлежности к дереву используются вместо подписи в сертификате. Это, фактически, перенос технических идей Certificate Transparency внутрь самих сертификатов. Я писал об этом новом подходе не так давно. С одной стороны – довольно интересная, изящная технология. С другой стороны – тут просматривается ещё большая технологическая привязка к тому же Google (потому что нужен будет совместимый TLS-стек в браузере, а реализовать такие технологии независимо – мало кому сейчас по силам; посмотрите хоть бы на внедрение ACME: там практически везде “готовые библиотеки/скрипты”, на обоих концах, что называется – мало кто понимает, как работает, но все используют и встраивают в свои системы на правах “чёрного ящика”). Но интересно, факт.

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

В сообщении Google (по ссылке выше) есть ещё интересный момент: там пишут, что к концу этого года ожидают (возможно, в Chrome/Chromium) поддержку X.509-сертификатов с “обычными” “постквантовыми подписями” для непубличных PKI (для УЦ, которые не входят в “коробочный” список доверия браузера). То есть, в браузере может появиться поддержка криптосистем подписи с постквантовой стойкостью в сертификатах. Это довольно занятно, так как позволит использовать такие сертификаты хоть в каких-то браузерах. (Но это ещё нужно посмотреть, что там реально будет.)

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

Перебор – перебором, но LLM-перебор – это совсем не тот перебор, который вполне себе является методом математического доказательства. Например, как метод доказательства, перебор позволяет быстро находить контрпримеры к каким-то утверждениям. Элементарная иллюстрация: допустим, кто-то говорит, что нельзя “квадрат разложить на два квадрата”; это легко опровергнуть, просто “подобрав” самую известную пифагорову тройку: 3^2 + 4^2 = 5^2. Естественно, компьютеры существенно улучшили возможности по перебору: несравнимы возможности современного ПК и даже таких признанных вычислителей, каким был Эйлер. Однако всё это без учёта новомодных LLM, в которых, похоже, вычислительный ресурс в основном расходуется впустую.

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

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

Недавно я писал, что Mozilla грозится Firefox переделать в “ИИ-бразуер” – то есть, вступает в эту безумную гонку. Но вот, однако, в новом выпуске Firefox 148 добавили “универсальную кнопку” для отключения “всех ИИ-функций браузера разом”.

Понятно, что всё равно это больше похоже на очередной маркетинговый трюк. Я уж не говорю о том, что не нужно было навязывать это. Но нет бы – убрать эти самые “ИИ-функции”, и активировать добавление их по прямому требованию пользователя, если уж ему нужно. Выбрали обратный вариант: типа, витрина, а вот тут можно “отказаться от всего этого богатства”. Если вы готовы, конечно – ведь тут столько всего нужного! Готовы? Уверены? Ну тут вот тогда подтвердите ещё раз, что отказываетесь от всех этих замечательных пунктов – вот их перечень, с выделением шрифтами – какие полезные штуки, а придётся отключить. То есть, стиль очень узнаваемый и, конечно, не радующий. Но хоть какие-то подвижки сделали в правильном направлении – может, потом и совсем одумаются, как говорится. (Если что – то я много использую браузер Firefox; надеюсь, что его всё же не доломают окончательно – браузеров и так почти не осталось.)

Даниэль Бернштейн (Daniel Bernstein) опубликовал сводную страницу (англ.) с информацией о “структуре спора” в IETF, который спор уже некоторое время идёт вокруг спецификаций, предлагающих использование в TLS негибридных криптосистем с постквантовой стойкостью (а именно – ML-KEM без дополнительных классических схем). Письма от Бернштейна, в рамках этой дискуссии, даже поставили на отдельную премодерацию в списках рассылки IETF – то есть, ограничили возможность что-то публиковать в этих списках. Там, на странице, предполагается, что продвижение негибридных вариантов ML-KEM через IETF – это “атака со стороны АНБ на уровне спецификаций”. Основные пункты, в поддержку и против, – организованы в виде дерева ссылок, по которому несложно понять, какие идеи/возражения есть, как они продвигаются; что весьма содержательно даже само по себе.

Например, есть интересный момент о том, что спецификации IETF не должны влиять на “внутренние реализации TLS”, потому что смысл деятельности IETF состоит в разработке спецификаций для Интернета в целом. Это в качестве ответа на предположение, что возможность “сломать совместимость TLS”, оставив там только негибридные схемы ML-KEM и полностью убрав ECC, не повлияет на “внутренние реализации”, где, мол, такое могло бы использоваться. Тут фокус в том, что спецификация TLS 1.3 делает поддержку криптосистем на эллиптических кривых обязательной, поэтому реализации, в которых такой поддержки нет (типа, для “экономии ресурсов”), не соответствуют спецификации (это будут дефектные реализации). Поэтому внедрение негибридных криптосистем, при наличии гибридных, – реально усложняет TLS (отмечу ещё раз, что TLS 1.3 – гораздо понятнее и логичнее, чем предыдущие версии спецификаций TLS; и странно это редкое для IETF преимущество ломать).

Не менее занимательно и странное утверждение в поддержку негибридных систем, основанное на размере ключей: мол, “отказ от части ECC в гибриде экономит место для ключей, что актуально для сред, где вычислительные ресурсы сильно ограничены”. Это странно потому, что, например, ключ ML-KEM имеет размер более килобайта (1184 байта), а та же схема X25519 (ECC) добавляет к ним только 32 байта. То есть, как справедливо замечено в возражении: “затраты на передачу и вычисление части X25519 пренебрежимо малы в сравнении с затратами на передачу ключей и шифротекста ML-KEM”. И верно: не нужно же забывать про чисто сетевые затраты, поскольку отправка и получение нескольких килобайт по TCP – это затраты на формирование заголовков пакетов, на копирование массивов, – которые, по размеру, будут за пределами возможностей быстрого преобразования, – затраты на переключение контекста, и так далее; поэтому разница в вычислениях между длиной 32+32 байта и длиной 1184 + 1568 байтов – может быть весьма разительна на некоторой аппаратуре, особенно, если говорить о средах с малой вычислительной мощностью.

В 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. Если по плану. Потому что документ предварительный и пока что выставлен для публичного обсуждения.