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

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

Отмечу отдельно пять записок из вышедших в марте 2026:

• Цифры и числа в системах счисления
• GNSS и трансляция координат в другую сторону
• Техническое: DNSSEC-ответы об отсутствии записей и RFC
• Уравнение Бомбелли и мнимая единица
• “Арифметика” Диофанта и обозначение неизвестной

Напоминаю, что в марте, вынужденно, поменялся домен сайта – теперь это dxdt.blog.

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

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

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

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

Казалось бы, это идеальная задача для ИИ/LLM. Современная ИИ/LLM, которая, якобы, на “уровне золотой медали Международной математической олимпиады”, должна легко такую задачу решить. Ведь эти системы “обучены” на огромном корпусе текстов, в котором упомянутые фразеологизмы встречаются постоянно (ну, как бы, “Весь мир – театр” и “Не всё то золото, что блестит” – куда же чаще?). Я, конечно, загрузил текст и картинку с задачкой в ChatGPT современной версии. Откровенно говоря, я, при всём моём скептическом отношении, думал, что хотя бы с парой фраз система справится. ChatGPT не угадало ни одной фразы. Так что задача даже лучше, чем можно подумать.

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

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

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

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

Я раньше несколько раз подробно описывал особенности DH и применение этого протокола в разных сценариях.