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

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

Всё потому, что эта система, по минимально сложным запросам, даёт выдачу сильно лучше, чем Google. Да, ответ генерируется в виде “статьи” на естественном языке, да, в ответе нередко ерунда написана, но “слова-то правильные”, а поэтому ответ нужно просто использовать как аннотированный список, тем более, что все ссылки можно открыть в отдельной панели (веб-версия) – и это будет та самая содержательная поисковая выдача, со “сниппетами”, которую раньше бы ожидали от Google.

Да, конечно, Google тоже занял большую часть страницы “выдачи” AI/LLM-генератором, и там тоже можно “пооткрывать ссылки” (кликнув на невнятные мелкие кнопки), но тут вопрос качества: субъективно, качество решения в ChatGPT сейчас несравнимо выше, а решаемая задача – та же.

Есть, впрочем, и существенная трудность: в ChatGPT очень долго готовится выдача. Так что, скорее всего, этим всё и объясняется – Google тоже хочет показывать AI, но уж точно не может позволить себе заставлять пользователя ждать две-три минуты.

Ещё немного о разных занятных исторических артефактах. В этом году исполнилось 55 лет с момента децимализации денежной системы Великобритании: 15 февраля 1971 года пенсы сменили новые пенсы, каждый из которых был в 2.4 раза дороже. Децимализация – это переход на десятеричную систему счёта денежных знаков: в фунте стало 100 новых пенсов. С этим процессом прямо связано исчезновение из обращения шиллингов – я публиковал об этом отдельную большую статью с картинками.

Но у нас есть ещё один артефакт по этой теме, который в ту статью не попал, однако фотографиями я поделюсь.

Это специальный набор монет Britain’s First Decimal Coins, официально выпущенный для ознакомления жителей Великобритании с новой системой – с десятеричными монетами. Это такая небольшая книжечка-раскладушка, в которой слева вложена картонная табличка с описанием того, что же именно происходит, а справа – картонная же вставка с набором подлинных монет – новых пенсов: в полпенни, один пенни, два пенса, пять пенсов и десять пенсов. Выглядит артефакт вот как.

Обложка:

Раскрытая книжечка:

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

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

Различные даты ввода в обращение, в том числе, планируемый 1971 год, – видны на самих монетах, см. увеличенный фрагмент ниже.

Надо заметить, что так как десятеричная система здесь относилась непосредственно к деньгам, в том числе, к наличным, она, так или иначе, прижилась, несмотря на различные конфликты и недовольство.

Кстати, а вот попалась мне монета в один бермудский доллар, в форме треугольника Рёло – фигуры с постоянной шириной: получается Бермудский треугольник Рёло.
На аверсе – портрет королевы Елизаветы II:

На реверсе – крушение корабля Sea Venture (как раз в Бермудском треугольнике):

(Фоном тут служит купюра в сто советских рублей, не обращайте внимания – к доллару с королевой купюра отношения не имеет.)

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

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

В общем, пока латинского текста нет, можно только строить предположения о первых словах: название “Magnifica Humanitas” наводит на очевидные варианты. Естественно, много кто уже догадался попробовать перевести текст “про ИИ” при помощи ИИ; например, с итальянского на латынь – но, понятно, это будет лишь упражнение в развитии постиронии: LLM не слишком хороши в подобных переводах.

Кстати, эта история с ИИ/LLM напоминает вот что. Есть такая известнейшая художественная работа, поставившая точку в целом направлении: “Чёрный квадрат” Малевича. Вряд ли кто-то сможет превзойти “Чёрный квадрат”. “Квадрат” – ценен контекстом, и, вообще говоря, являлся опорным элементом для большего перформанса. Впрочем, сейчас – о другом аспекте.

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

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

Вот так и с ИИ/LLM.

Часто попадаются фразы, что, например, алгоритм ML-KEM – это алгоритм, “стойкий к подбору на квантовом компьютере”. Вопрос, конечно, терминологический, но попробуем разобраться, почему такая формулировка (“стойкий к подбору”) – не верная, и почему так писать нежелательно.

Более или менее строгое определение: “ML-KEM, теоретически, обладает стойкостью к взлому при помощи алгоритма Шора”.

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

Однако здесь “эффективно реализующего алгоритм Шора” – это просто характеристика компьютера, который, вообще говоря, полагается универсальным (в текущей, так сказать, степени понимания “универсальности”). Впрочем, заметьте, что основной исходный посыл тут – это именно “неприменимость” алгоритма Шора. Так что определение про “стойкость к алгоритму Шора” – тоже верное. Потому что те криптосистемы, на замену которым предложен алгоритм ML-KEM, – разновидности ECDH, RSA и др., – уязвимы именно к алгоритму Шора.

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

Во-вторых, никто не доказал, что невозможны другие “квантовые алгоритмы”, которые, – на подходящем, но гипотетически реализуемом, квантовом компьютере, – будут успешно и быстро взламывать ML-KEM. А если учитывать, что модели квантовых вычислений легко оперируют континуумом (синусы/косинусы и действительные числа), то, вообще говоря, не стоит делать ставку на то, что теоретический “квантовый алгоритм подбора ML-KEM” не придумают в обозримом будущем. Более того, сейчас распространено мнение, что в том самом обозримом будущем гораздо более вероятно появление практической классической атаки на ML-KEM, чем появление квантовых компьютеров, способных сломать ту же X25519 (разновидность ECDH) алгоритмом Шора. То есть, криптосистема ML-KEM может оказаться уязвима для обычных компьютеров, а X25519 и другие современные варианты ECDH – сохранят классическую стойкость.

Как же вообще нужно именовать эти криптосистемы, типа ML-KEM? Например, я и сам регулярно использую термин “криптосистемы с постквантовой стойкостью”, но это тоже не слишком-то хороший вариант, поскольку, откровенно говоря, он не так далеко ушёл от стойкости “к подбору на квантовом компьютере”, как хотелось бы. Конечно, “постквантовая стойкость” здесь – это стойкость к алгоритму Шора. Но это лишь подразумевается, а сам термин – чрезмерно широкий. Видимо, наилучший вариант, который уже сложился исторически, это просто “постквантовые криптосистемы”. То есть, такие криптосистемы, которые предлагается использовать после появления доступных универсальных квантовых компьютеров, и акцент тут – на слове “универсальных”.

Продолжаю потихоньку закрывать то, что адресуется в .ru, .su: убрал A-запись из nox.su, планирую в ближайшие дни отключить там DNSSEC. (Под nox.su была страничка с описанием DNSSEC и примерами настройки.)

(Update, 24/04/2026: отключил для nox.su DNSSEC, удалил DS-запись из зоны .su.)

Открытый серверный ключ 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. Но как только и если появится квантовый компьютер подходящей разрядности, тогда можно будет секретные ключи подобрать очень быстро.

У меня есть очень старый аккаунт Google Apps “для домена” – ещё со времён бета-тестирования, бесплатный (каким-то чудом). Вот я настраивал там TOTP, поскольку Google перестал пускать без “второго фактора” (очередной маркетинговый трюк), и обнаружил, что в панели администратора теперь есть специальный раздел “Углеродный след” (Carbon Footprint for Google Workspace). Кто бы мог подумать.

В копилку примеров реального использования ИИ/LLM.

Попробовал тут выяснить, можно ли через ChatGPT узнать о группах для протокола FFDH (“мультипликативного” Диффи-Хеллмана, DH), используемых в TLS 1.3. Довольно специальный вопрос. Но зато вполне конкретный. Удивительно, но ChatGPT 5.2 тут же верно сообщило и номер RFC, где описаны эти группы, – RFC 7919, – и о том, что группы строго зафиксированы, что их всего пять. Это всё верно. Но, как обычно в таких делах, не будем торопиться с выводами.

То есть, подразумеваем, что ChatGPT тут использует человек, хорошо знакомый с математической частью, но который хочет узнать технические детали DH конкретно в TLS 1.3. Первая выдача ChatGPT, пусть и содержала какие-то домыслы про HSM и пр., но оказалась бы в таком сценарии полезной: номер RFC, информация о том, что используется зафиксированный набор групп, в общем – по теме и неплохо. В этом-то и кроется ловушка, как будет видно далее: данная система легко, с первого шага, производит впечатление “информированной”, но таковой не является.

Следующим запросом я попробовал выяснить значение конкретного модуля конкретной группы (основной параметр, задающий группу для FFDH, – простое число, называемое модулем). Опять же, удивительно, но ChatGPT даже смогло “понять” и корректно обработать опечатку в моём запросе: я пропустил одну цифру, написав ffdhe372 вместо ffdhe3072.

“В TLS нет группы под названием ffdhe372” – верно сообщило ChatGPT (здесь и далее я перевожу с исходного английского). “Вы наверняка имели в виду ffdhe3072 (RFC 7919, Group 15)” – уточнило ChatGPT. Что это за “Group 15” – непонятно, но, ладно, в остальном – очень верно. Именно ffdhe3072 и имелась в виду. Опять же, выглядит, как ответ очень “информированной” системы. Не то чтобы исправление подобных опечаток с использованием статистики корпуса текстов представляло какую-то техническую трудность, но, тем не менее, создаёт впечатление “подлинности”.

Ещё более удивительно, но ChatGPT распечатало абсолютно верное значение модуля – цифра к цифре. Это, конечно, улучшение, если сравнивать с тем, что было пару лет назад. Но дело тут не в данном улучшении, как вы, думаю, уже догадались: ChatGPT и сейчас легко генерирует несуществующие цитаты – я недавно сталкивался с тем, например, что оно сгенерировало ложную цитату “из труда Бомбелли”. Опять же – очевидно, что внутри ChatGPT нет никакой точной “базы знаний”, откуда оно могло бы извлекать подобную информацию универсальным образом – значение модуля, в данном случае. Но если смотреть узко, то складывается впечатление, что такая база там есть, что ChatGPT сходило в сохранённый текст RFC и скопировало оттуда значение модуля.

Нет. Всё не так, несмотря на непрерывное маркетинговое давление.

Дальше я спросил, как доказывается, что это – простое число. (Модуль должен быть простым числом, это базовое требование.) И тут ChatGPT кинулось в рассказы о тестах на простоту, о “доказуемо простых” числах и т.д., заявив, что использовался “алгоритм Маурера” (Maurer) и написав тому подобные техничные слова. Проблема в том, что это всё общие методы, не имеющие отношения к конкретному RFC и к конкретному модулю.

То есть, ChatGPT заявило, что простые модули в RFC 7919 выбирались методом Маурера (или по алгоритму, это не важно), начиная с некоторого небольшого известного простого. Это совсем не верно, но звучит очень похоже на правду, если только вы уже не знаете технических деталей. Такой вот ловкий обман. Естественно, тут же ChatGPT добавило показательный, по своему ложному положению, текст: “если бы в TLS использовались простые числа, похожие на случайные, но без доказательств, то злонамеренная сторона-генератор могла бы встроить бэкдор”. Этот фрагмент дословно верный, но только если его рассматривать вне контекста обсуждения и исходного запроса. А если в контексте, то под “доказательствами” тут имеются в виду “сертификаты” (“свидетели”) простоты числа, и это не имеет отношения к методу “защиты от бэкдоров”, который должен быть направлен на исключение возможности получения числа специального вида – доказательства тут должны доказывать то, что алгоритм не позволяет выбрать произвольное простое число, а числа там всегда простые. (Да, математически, наличие “сертификатов”, доказывающих простоту, – вычислительно ограничивает возможности по свободной генерации простых, но тут речь точно не об этом, да и ограничения там не являются блокирующими.)

Итак, следующий мой вопрос был о том, как же именно был получен модуль ffdhe3072.

Метод вычисления всех модулей из RFC 7919 описан в самом этом RFC. Буквально. Я как-то даже писал об этом подробно. В основе вычисления – запись числа e. В этом весь смысл: числа взяты “из записи” e, а не придуманы “с бэкдорами”. Схема называется NUMS – Nothing Up My Sleeve (“ничего в моём рукаве”).

То есть, если бы в ChatGPT был интеллект, – пусть и искусственный, – то этот “интеллект” взял бы RFC и прочитал. Тем более, что так хорошо всё начиналось. Но нет. ChatGPT стало продолжать в красках расписывать, что модули для RFC 7919 были получены по “детерминированному алгоритму Маурера”, прямо приводя фальшивый способ получения исходной константы: seed = SHA-256(“TLS FFDHE 3072”). Да. Настолько детально. И так далее, и тому подобное. Никакого отношения к RFC и к оригинальному источнику значений модулей – в этом не было (в RFC, ещё раз, написана конкретная формула, но она вообще не имеет отношения к “Мауреру”).

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

P.S. А число, полученное как SHA-256(“TLS FFDHE 3072”), – составное: 0xd73d45623a7a52d11ea654956e701554a137fafd3545d46379891d7c4c79f545 = 3^2 * 7 * 3719447821 * 27939151181 * 3616471485699239 * 4111907187916820252669152053322571860357.