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

Кто-то опубликовал черновик (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 для публикации черновика – кто угодно может опубликовать черновик.

Благодаря влиянию ACME и Let’s Encrypt, сейчас стала очень популярной схема подтверждения права управления доменом (DCV) через DNS, но при помощи размещения CNAME-записей. Речь про запрос TLS-сертификатов средствами автоматизации – скриптами (acme.sh, certbot и др.). Напомню, что DCV здесь состоит в проверке размещения TXT-записи с кодом подтверждения под заданным именем в DNS-зоне (это метод DNS-01). ACME использует специальный префикс: _acme-challenge.

Однако CNAME – это не TXT-запись, а способ перераспределить проверку в другую DNS-зону (см. детали ниже). Вообще, протокол ACME в данном сценарии не требует ни использования, ни даже поддержки CNAME. Но такая поддержка массово используется, и её сейчас принято обосновывать тем, что можно, мол, “не предоставлять доступ к исходной зоне скриптам автоматизации”. Использование CNAME – вообще плохая практика, а особенно плохая практика – это использование CNAME в процессе DCV. Что, конечно, не мешает массовому распространению. Вообще, с подобным использованием CNAME, – то есть, в DCV, – связана пара занятных технических моментов, о которых забывают.

Момент первый: постоянно путают синоним (алиас) и основное имя в CNAME. Дело в том, что CNAME – это Canonical NAME (каноническое имя), и каноническим является именно значение записи, а не имя-носитель. Имя-носитель – это и есть алиас, что бы там ни писали в инструкциях к средствам автоматизации ACME. Если для example.com в CNAME-записи указано 1.2.3mega-blah-blah.example.net, то вот это вот 1.2.3mega-blah-blah.example.net и есть основное имя. При использовании в ACME предлагается настроить CNAME для префикса _acme-challenge. Например, _acme-challenge.example.com в 1.2.3mega-blah-blah.example.net. Но и тут алиасом, в терминах DNS, будет _acme-challenge.example.com, префикс не влияет на отношение значений записей. Такова семантика CNAME.

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

Естественно, можно рассуждать иначе: если утрачено каноническое имя, то нужно удалить CNAME-запись в алиасе; тем более, что так как сертификаты сейчас “короткие”, утрата канонического имени обнаружится быстро. Это верно. Более того, имея контроль над исходной зоной (в которой CNAME) – можно будет попробовать отозвать сертификаты для этой зоны, если такие были выпущены при помощи подхвата CNAME. (Один из штатных способов отзыва сертификата в ACME – прохождение DCV для имён из сертификата; но нужно предъявить сам сертификат, и должно всё сойтись по составу имён – то есть, если в подставном сертификате указана ещё какая-то зона, то могут быть проблемы с отзывом.) Однако это всё только теоретические рассуждения, в стиле “как должно быть”, а на практике, как говорится: ну, на практике-то – и про CNAME-зоны забывают, и про обновление имён, и про отзыв.

Момент второй: реальный доступ к зоне. Из первого момента, с каноническим именем, легко выводится этот второй: да, использование CNAME предлагают в качестве решения проблемы “расползания реквизитов доступа”. Мол, не хочется давать скриптам ACME доступ к редактированию нашей важной доменной зоны, поэтому пропишем CNAME и дадим доступ в другую зону, не такую важную. Но, как бы, смысл DCV – проверка права управления доменной зоной, а тут – это право управления прямо предлагают не выдавать, а подменить саму зону средствами DNS. Опять же, такая трактовка – не “перегиб”: дело в том, что управление зоной должно, если по-хорошему, подтверждаться при каждом выпуске сертификата (ну, хорошо, с некоторым интервалом по времени действия успешной проверки), а CNAME, направленная на каноническое имя – это долгий и универсальный вариант, не привязанный к выпуску сертификата вовсе. Для чего, собственно, использование CNAME и затевается. Опять противоречие.

Кстати, тут полезно вспомнить, что есть и суперновая версия DNS-проверки в ACME – с “постоянной” привязкой ACME-аккаунта к имени: вот где совсем не место CNAME (но черновик RFC пока что их не запрещает явно).

CNAME-записи – одни из самых сложных по поведению в DNS, а их использование – источник неожиданных проблем. В случае DCV, семантика и принципы интерпретации CNAME вообще противоречат основной логике проверки права управления через DNS. Что касается других решений: во-первых, ACME-префикс можно делегировать на отдельные NS, без всяких CNAME; во-вторых, для размещения TXT-записей вовсе не обязательно передавать полные права управления DNS-зоной каким-то скриптам. Это всё решения на стороне, заказывающей DCV. Но самое правильное, конечно, это не следовать CNAME при проверке DCV на стороне систем УЦ.

О тонкостях литературного английского. В известном произведении The Hitchhiker’s Guide to the Galaxy (“Путеводитель хичхайкера по Галактике”/”Автостопом по Галактике”) Дуглас Адамс, описывая в одной из глав свершения смелых космических первопроходцев, использует следующую фразу (выделена пожирнением):

And all dared to brave unknown terrors, to do mighty deeds, to boldly split infinitives that no man had split before – and thus was the Empire forged.

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

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

Дословный перевод выделенного фрагмента, но с учётом общего контекста в оригинале: “смело разделять инфинитивы, которые никто не разделял прежде” – но эта фраза на русском выглядит странной и пустой. Так и должно быть, а детали придётся разбирать отдельно.

Прежде всего – “to boldly split”. Это явление, которое в английском языкознании называется split infinitive – “расщеплённый” инфинитив (можно обозначать и другими русскоязычными терминами, но здесь будет “расщеплённый”). Инфинитив – infinitive – это неопределённая форма глагола: “знать”, “читать”, “писать”. В английском языке инфинитив записывается (но не образуется, заметьте) при помощи to – примеры: to know, to write, to read. Расщепление – это практика внедрения между to и “глаголом инфинитива” одного или нескольких дополнительных слов; обычно, внедряется наречие, как и в нашем случае: to boldly split. И этот грамматический процесс относится к одному из самых спорных моментов. Причём споры, с викторианских времён, идут среди образованных носителей английского. Многие и сейчас считают такое расщепление недопустимым нарушением грамматического строя, речевой ошибкой. Но это, ещё раз, мнение спорное.

To boldly split – нетрудно перевести как “смело (или отважно) разделять”. Проблема в слове boldly. Строгие варианты такие: “boldly to split” или “to split boldly”. Но ни один, ни другой – не выглядят смешно. Прежде всего потому, что сама эта фраза – прямая отсылка к оригинальному сериалу Star Trek. Фраза-заставка к эпизодам этого классического сериала известна как “Where no man has gone before”, и используется постоянно. Этим словам, в оригинальном тексте вступления, предшествует не менее знаменитое (но уже в узких кругах) “To boldly go”.

Расщепление полностью, в версии Star Trek, будет таким: “To boldly go where no man has gone before!” – “Смело идти туда, где не ступала нога человека!”. Заметили тот самый расщеплённый инфинитив? To boldly go. Это и есть предмет аллюзии: грамматически спорная конструкция о том же boldly, расщепляющем инфинитив (многие литераторы и филологи, – особенно, в 60-х годах 20 века, – скажут, что это не “спорная”, а точно грамматически неверная конструкция).

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

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

В оксфордском словаре Фаулера (H. W. Fowler, A Dictionary of Modern English Usage, изд. 1965) есть замечательный пример фразы, в которой попытка избежать расщепления инфинитива приводит к плачевным последствиям:

The greatest difficulty about assessing the economic achievements of the Soviet Union is that its spokesmen try absurdly to exaggerate them; in consequence the visitor may tend badly to underrate them.

То есть, экономические достижения Советского Союза – “его представители абсурдно пытаются преувеличивать”, а посещающие СССР, в результате, “сильно/грубо недооценивают их”. Здесь наречия (“абсурдно”, “сильно” или “грубо”) оказываются прицеплены не к тем глаголам, что звучит несколько странно. И странность звучания помогает понять второй аспект юмора “расщепляющихся инфинитивов” в первоначальной цитате из The Hitchhiker’s Guide to the Galaxy, который в русском переводе тоже передать невозможно, по причине отсутствия в русских инфинитивах расщепимости.

(На День Космонавтики эту записку выпустить не успел – что-то завозился, – но, думаю, ещё не поздно: да и не откладывать же на следующий год, верно? С прошедшим Днём Космонавтики!)

В рамках “ренейминга”, связанного с миграцией сайта с доменов .ru, сделал субординатные имена авторитатвиных серверов DNS для dxdt.blog. “Субординатные” – означает, что имена авторитативных серверов (NS) находятся в той же зоне, которая делегирована на эти серверы: например, ns1.example.com, ns2.example.com для example.com. Такую схему именования ещё иногда называют “красивые NSы”. В случае dxdt.blog, имена NS-ов – в зоне dxdt.blog.

Соответственно, делегирующий ответ с такими именами обязательно содержит так называемые glue-записи – то есть, записи с информацией об IP-адресах NSов. Иначе рекурсивный опрос не будет работать, так как зациклится. Я об этом писал неоднократно, в том числе, про сложную рекурсию, связанную с перекрёстными зависимостями.

Например, сама зона .blog размещена на NS-ах с субординатными именами:

alex@garlic-crusher:~$ dig blog. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
blog.			172800	IN	NS	a.ns.nic.blog.
blog.			172800	IN	NS	d.ns.nic.blog.
blog.			172800	IN	NS	c.ns.nic.blog.
blog.			172800	IN	NS	b.ns.nic.blog.

;; ADDITIONAL SECTION:
[...]

– здесь имена авторитативных серверов в ns.nic.blog., пусть для корневой зоны это и не имееет большого значения (см. ниже). Да, субординатные имена популярны, однако мне подобная схема именования не очень нравится. Другой вариант, из зон верхнего уровня, можно наблюдать в .ru:

alex@garlic-crusher:~$ dig ru. -t NS @a.root-servers.net
[...]
;; AUTHORITY SECTION:
ru.			172800	IN	NS	a.dns.ripn.net.
ru.			172800	IN	NS	d.dns.ripn.net.
ru.			172800	IN	NS	f.dns.ripn.net.
ru.			172800	IN	NS	b.dns.ripn.net.
ru.			172800	IN	NS	e.dns.ripn.net.

;; ADDITIONAL SECTION:
[...]

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

Эта монета весит, примерно, 12.14 грамма, а её диаметр – чуть более 31 мм: ко Дню Космонавтики – ракета, в виде памятника, Спутник и космическая станция, как они видны на реверсе олимпийского рубля времён СССР.

Решил посмотреть, как Google переиндексирует ссылки с dxdt.ru на dxdt.blog – попутно наткнулся на ИИ-выдачу, в которой попалась забавная интерпретация названия одной из тем сайта.

На Dxdt есть категория “О рениксе”, к которой я отношу заметки, рассказывающие о проявлениях разной чепухи – что, в общем, не удивительно: слово “реникса” – это из пьесы Чехова, где оно возникает в анекдоте про неверное прочтение слова “чепуха”, записанного курсивом. И действительно: кириллическая строчная “ч”, рукописным курсивом, выглядит как курсивная же латинская “r”. Unicode, к сожалению, воспроизвести не позволяет. Хоть соответствующий символ там и имеется – Mathematical Script Small R, – но вот в шрифтах он, обычно, выглядит как “правая” “рукописная” r: 𝓇.

В общем, Unicode – юникодом, но исходное русское “чепуха” в анекдоте из пьесы Чехова выглядит как “renyxa”, то есть, “реникса”, если читать на латыни, хоть такого латинского слова и нет. Ну, как нет – тут-то система Google LLM для поиска (разновидность Gemini?) слово “подходящее” нашла, написала, что “О рениксе” происходит от латинского renixus, которое есть вариант renisus – “сопротивляющийся”. Мол, тут игра слов: с одной стороны – “чепуха”, а с другой – реальное латинское слово. Так-то.

Из 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. И веб-сервер придётся обновить, конечно.

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

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

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

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

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

Открытый серверный ключ TLS, который указан в TLS-сертификате, на dxdt.blog начинается с подстроки DEADC0DE (в шестнадцатеричной записи, см. скриншот ниже).

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

Как это значение получено? Оно получено перебором, конечно. Это не очень сложно сделать. Открытый ключ ECDSA – это точка на кривой. Точке соответствуют две координаты, одна из них (обычно, обозначают X), записывается слева. Поэтому в начале записи ключа будут идти старшие байты X-координаты. Остаётся подобрать такой секретный ключ, который даст открытый с нужной X-координатой. Секретный ключ – это натуральное число, больше двух и меньше порядка группы точек кривой (обычно, меньше тоже на два, но это детали). Нужно перебирать секретные ключи и проверять значение начальных байтов X-координаты открытого на соответствие заданной маске.

Открытый ключ – это точка-генератор G из параметров кривой, умноженная на значение секретного ключа d: [d]G. Я, используя готовую библиотеку из дистрибутива языка Go, написал быструю программу умножения на P-256 (кривая, которая используется здесь в ECDSA). Программа перебирает секретные ключи и делает это параллельно, во много потоков. Соответственно, даже на старом 16-потоковом процессоре AMD Ryzen 7, подбор ключа занял всего несколько часов. В результате подбора я получил нужный секретный ключ, который экспортировал для генерирования CSR (запрос на выпуск сертификата) и штатным способом использую при заказе TLS-сертификатов.

Вообще, для P-256 можно придумать немало открытых ключей, запись которых, в X-координате, выглядит ещё более необычно. Например:

0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBA
- цифры A и немного B,
0x1000000000000000000000000000000000000000000000000000000000000001
- единицы и нули,
0x5000000000000000000000000000000000000000000000000000000000055555
- пятёрки и нули,
0x7777777777777777777777777777777177777777777777777777777777777777
- семёрки с "неожиданной" единицей,
0x8888888888888888888888888888881888888888888888888888888888888888
- восьмёрки, но тоже с единицей.

Точки с такими X-координатами лежат на кривой P-256. Определить для них Y-координату – не представляет вычислительной проблемы. Более того, ввиду свойств данной кривой – все эти точки, действительно, являются открытыми ключами. Тут есть лишь одна проблема: по открытому ключу очень сложно, а на практике – невозможно, вычислить секретный ключ; потому что это и есть основная задача, обеспечивающая стойкость ECDSA. Конечно, подходящий секретный ключ можно угадать. В том числе, в результате перебора. Вот только перебрать даже половину от, примерно, 2^256 – нереально. Ну и записать подходящий секретный ключ просто по наитию, как поступил бы борелевский шаман, пока что тоже не вышло. Так что придётся, до поры до времени, обойтись без забавных записей, ограничившись hexspeak-вариантом с DEADC0DE. Но как только и если появится квантовый компьютер подходящей разрядности, тогда можно будет секретные ключи подобрать очень быстро.

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

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

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

Если посмотреть на запись прямоугольного сигнала с “разложением по частотам”, полученную при помощи преобразования Фурье, то вместо одного пика на главной, расчётной, частоте, будет видно много пиков с постепенно затухающей амплитудой, которые пики, для идеального случая, соответствуют “нечётным множителям частоты”, побочным гармоникам (то есть, для идеального меандра 1 кГц – будет 3 кГц, 5 кГц и т.д.). Здесь важно учитывать, что реальный сигнал всегда очень далёк от идеального (если говорить строго, то бесконечно далёк), поэтому могут быть видны и чётные гармоники, и всякий прочий шум в частотах, но с гораздо меньшей амплитудой, вообще говоря. Впрочем, чётность здесь не так уж важна, поскольку главный вывод такой: гармоники, действительно, хорошо видны на экране анализатора спектра с преобразованием Фурье.

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

Гармоники преобразования Фурье принято записывать “синусоидами” (или “косинусоидами” – особой разницы, для наших целей, нет). Существуют ли эти непрерывные гармоники записи в самом исходном сигнале? Ведь наш исходный сигнал – прямоугольный. То есть, – во временной области, – это просто переключение уровня: плюс/минус. Как на картинке из записки про меандр и микроконтроллер – см. ниже.

Здесь нет никаких “синусоид”, то есть, нет никаких дополнительных гармоник. Или они есть? Потому что, как мы только что выяснили, если такой идеальный сигнал вывести на экран того или иного анализатора спектра, использующего преобразование Фурье, то гармоники там обязательно появятся, в большом количестве. Но важно не путать модель с исходным процессом. Анализатор спектра не может дать другого изображения: прямоугольный сигнал невозможно записать при помощи одной гармоники, таких гармоник потребуется много; а для точной записи идеального прямоугольного сигнала – бесконечно много. Понятно, что никакой анализатор спектра не может ни показать, ни обработать бесконечно много гармоник, а лишь некоторую их часть. Ситуация тут схожа с записью рационального числа 1/3 в виде десятичной дроби: 0.3333[3] и так далее. Но всё равно – это только запись.

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

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

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

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

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