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

Процитирую записку из 2013 года:

“Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа”.

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

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

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

Это всё, впрочем, не отменяет постапокалипсиса в истории Интернета. Но, как в цитате выше, эта группа технологий не дождалась своего часа – то есть, не была применена в соответствии с легендой. И уже не будет. Сейчас схемы иные.

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

Поэтому-то шансов на разыгрывание легенды по привычному сценарию – больше нет.

У меня в GitHub тоже есть аккаунт, которым, впрочем, я почти не пользуюсь. Но это не отменяет важности GitHub, конечно. Я под своим там аккаунтом довольно давно опубликовал реализацию шифра “Кузнечик” с оптимизацией на ассемблере Go (гораздо более новая версия, с поддержкой ARM64, есть у меня на сайте, если это вообще кому-то нужно). Кроме того, на GitHub я как-то выложил Runic32 – реализация Base32 на алфавите из англосаксонских рун (“футарк/футорк”, условно говоря). Этот проект является шуточным – потому что как-то зашёл разговор о том, что “TLS-сертификаты отображаются какими-то крючками”: ну, вот, при помощи утилты runic32 можно сертификаты записывать прямо рунами (если есть Unicode).

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

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

Даниэль Стенберг (утилита curl) сообщает, что “страшная-ужасная” система поиска уязвимостей в ПО Mythos нашла в коде утилиты curl “пять” “подтверждённых уязвимостей” (“подтверждённых” – по мнению данного ИИ-LLM), которые, после проверки разработчиками, превратились в одну действительно подтверждённую уязвимость с низким уровнем опасности. Четыре остальных представленных описания – это ложные срабатывания и обнаруженная ошибка, – не уязвимость, – в коде. Результат никак не превосходит уже имеющиеся на стороне разработки curl инструменты.

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

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

Consequently, for the same “key tag” (33834), three different key pairs were generated instead of a single one, of which only the public key of a single pair was stored in the DNSKEY RR, meaning that only about a third of the RRSIG RRs could be validated. (В результате, для одинакового “тега ключа” (33834) были сгенерированы три разных ключевых пары вместо одной, из которых только открытый ключ единственной пары был размещён в DNSKEY-записи, что привело к тому, что только треть из RRSIG-записей могли быть валидированы.)

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

Собственно, в недавней записке об аварии DNSSEC в .DE я поэтому и упомянул конфликты тегов ключей DNSSEC, которые теги используют не по назначению. Цитата:

В DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.

Оказалось – в этом и была проблема. Что тут ещё сказать? Бывает, конечно: ведь с пониманием сложных процессов – сейчас трудности везде.

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

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

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

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

Хотя – хайп. Хайп не все хотят пропустить.

В домене .DE на некоторое время сломались подписи DNSSEC. Сейчас уже пишут, что починили. Возможно, тоже перепутали ключ из-за совпадающих тегов. (Лирическое отступление: в DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.)

Интересна тут реакция Cloudflare, как оператора одного из самых распространённых в этих интернетах сервиса DNS-резолвинга – 1.1.1.1: в Cloudflare, после локализации ошибки на стороне DE, валидацию DNSSEC для этой зоны просто отключили. Ну, то есть, очередной пример реальной ценности DNSSEC в современой глобальной DNS: если что не так, то систему валидации принято отключать; но, конечно, не просто так отключать, а информированно отключать.

Есть даже RFC 7646, который, кто бы мог подумать, прямо предписывает так делать. Естественно, речь тут идёт об операторах DNS-сервисов, которые могут убедиться, что, мол, “это не атака подмены”, а это DNSSEC сломали сами администраторы ключей, очередной раз. Хотя, строго говоря, достоверно определить, что подписи стали расходиться не из-за атаки, а из-за ошибки – весьма и весьма сложно: атака могла быть на уровне оператора реестра, например. Может ли тут что-то с уверенностью – и, главное, быстро, – сказать внешний наблюдатель, даже если он оператор резолвера? Ну, это вряд ли. Остаётся полагаться на ответы оператора реестра и, что называется, кликать виртуальную универсальную кнопку “Всё равно продолжить” для всех пользователей своего “валидирующего” резолвера. Такая вот нынче стала на практике эта технология – DNSSEC. Ничего не поделать.

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

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

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

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

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

Момент первый: измерение параметров времени для TCP-соединения. Например, к некоторому веб-сервису подключается клиент, скажем, браузер. При помощи выполнения некоторых скриптов не очень трудно померить время “сетевой задержки” между средой веб-страниц этого браузера и серверной средой. То есть, это будет время доставки запроса, измеренное от контекста DOM в браузере до веб-сервера. Предположим, это 50 ms. Но это всё по HTTP, а HTTP-соединение использует TCP.

TCP-соединение устанавливается не с браузером, а с логически ближайшим к серверному сетевому стеку узлом. Это может быть клиентский компьютер, то есть, ОС на этом компьютере. Но может быть и выходной узел, выполняющий трансляцию адресов, например. Обычно – именно так и есть: клиентский компьютер редко стоит прямо за маршрутизируемым IP-адресом. Тогда, если измерять и задержку в браузере, и задержку на серверном TCP, то получится, скажем, что, в рамках одной логической HTTP-сессии, TCP-задержка – 10 ms, а браузерная задержка, до DOM в HTTP-клиенте, – 50 ms. Большая разница – 40 ms. Это означает, что от клиента транслированные запросы ещё где-то там внутри долго ходят, пока доберутся до выходного узла, который к нам по TCP подключился.

Если же выходной TCP-узел примерно совпадает с логическим узлом, где работает клиентский браузер, то разница между двумя задержками будет минимальной, например: 10 ms TCP и 11 ms – браузерная задержка, читай – Javascript в DOM-контексте. Здесь под “примерно совпадает” имеется в виду, что между клиентским компьютером и выходным узлом нет большого сетевого плеча: компьютер и выходной узел стоят технически рядом (простейший случай: локальный пограничный “роутер” с NAT и подключенный к этому “роутеру” по локальному порту компьютер в локальной IP-сети над Ethernet-ом).

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

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

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

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

Сюда же попадает и повсеместная путаница, связанная с распределением блоков IP-адресов (префиксов). У всякого IP-префикса есть администратор – автономная система (AS). Это верно. Но ещё есть маршрутизация и BGP. И вот в рамках BGP, технически, быть источником (origin) для данного IP-префикса может любая (подчёркиваю: технически – любая, даже с тестовым номером) автономная система. То есть, административно, префикс принадлежит одной AS, но анонсирует его в Интернет – совсем другая. Или даже несколько других AS – в зависимости от того, какой оператор из какой точки сети смотрит на BGP. Да, для штатного анонсирования префикса должно быть разрешение от его администратора, сейчас это даже подтверждается в RPKI. Да, конкретная ситуация с приёмом IP-пакетов зависит от фильтров, настроенных оператором. Но это только подчёркивает то, что одно дело – административная принадлежность, другое – BGP и маршрутизация в реальности.

BGP – это хорошо, но при чём здесь сетевые задержки? Вот при чём: даже во внешнем BGP, например, не видны многие и многие внутренние каналы между операторами, более того, административная принадлежность префикса не позволяет судить о реальных характеристиках сетевой связности вообще никак; однако разные пути доставки тут всё равно образуются, и разное время доставки, наблюдаемое внутри, вполне себе может служить признаком для классификации.

Кто-то опубликовал черновик (draft) с описанием IPv8, очевидно, сгенерированный при помощи LLM: там во первых же строках предлагается аутентификация узлов с OAuth2, JWT-токенами, “из локального кеша”, и валидация каждого интернет-пакета через специальный DNS8 – дальше же можно не читать черновик, не тратить время. Печально, но теперь пишут на профильных сайтах, что это “организация IETF” выставила “черновик новой версии протокола IP”. Однако на странице данного черновика прямо, на специальной плашке, написано, что IETF никак данный черновик не поддерживает: “This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process”. Что, конечно, не удивительно: потому что не требуется одобрение и поддержка IETF для публикации черновика – кто угодно может опубликовать черновик.

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

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

Самое интересное в озвученных планах, что на середину 2027 года (следующий год) запланирована защита постквантовыми криптосистемами цепочки аутентификации для подключающихся клиентов – это, как указано, сертификаты на хеш-деревьях (с ML-DSA, скорее всего). (MID 2027: PQ authentication support for visitor → Cloudflare connections using Merkle Tree Certificates.)

В Google недавно намекали на то, что поддержка постквантовых криптосистем подписи для TLS и X.509-сертификатов появится в Chrome/Chromium уже к концу 2026 года. И в это можно поверить, потому что сами технические средства в виде программного кода и описаний структур – довольно давно готовы, а полная реализация имеющимися средствами конкретно для TLS-сертификатов неоднократно продемонстрирована на практике.

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

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

Что вообще нужно для перехода на постквантовые криптосистемы в этом технологическом контексте? Понятно, что веб-TLS здесь является локомотивом. Понятно, что нужна подержка на серверной стороне – а это обещает и Cloudflare, и Google (другие, начиная с Microsoft, скоро подтянутся – не сомневайтесь). Понятно, нужна поддержка в браузере – это обещает, на это намекает Google (вообще, тут – именно обещает, потому что эксперимент Cloudflare и Google по вндрению сертификатов на хеш-деревьях – уже идёт). Остаётся поддержка на стороне УЦ, да. Но и Cloudflare, и Google – это УЦ: и “фактически”, и “практически”.

Да, нужна поддержка на стороне обычных серверов, в виде утилит для выпуска ключей и запросов на сертификаты всеми желающими. То есть, обычный сейчас вариант с ECDSA или RSA – не подходит: эти криптосистемы не обладают постквантовой стойкостью, теряется смысл даже в том случае, если УЦ подписывает постквантовой криптосистемой. Вручную же ключи генерировать могут не все, а тем более – использовать в веб-сервере. Нужны автоматические утилиты. Однако, распространение ACME-автоматизации – certbot и пр. – позволяет процесс автоматизировать и тут, сведя весь переход к обновлению версий системных библиотек и скриптов для заказа сертификатов через ACME. И веб-сервер придётся обновить, конечно.

В общем, не выглядит неральным, но посмотрим.

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

Artemis II – это пристрелочный облёт Луны. Без этого, понятно, никак. Но, всё же, до высадки – ещё далеко. Очередная высадка на Луну – только запланирована на 2028 год: это Artemis IV. 2028 год – очень близок, верно, однако и глобальные обстоятельства какие-то не слишком радужные. При этом ещё и во многих крупных СМИ уже сейчас объявляют о “возвращении на Луну” – как бы, бег впереди паровоза в данной области ранее очень не приветствовался. Но посмотрим.