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

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

“Шёл с косой косой косой”.

Что здесь написано? Например, это сказочный заяц (косой или Косой), который идёт, неся на плече ручной инструмент для покоса травы, но этот инструмент довольно кривой: “коса у зайца на плече косая”.

Теперь допишем ещё одно слово “косой”.

“Шёл с косой косой косой косой”.

Что получилось? Теперь заяц-косой ещё и реально косой – то есть, у него большие проблемы с глазами.

“Шёл с косой косой косой косой косой”.

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

“Шёл с косой косой косой косой косой косой”.

Предположим, что и песчаная коса – тоже косая, на то она и коса. Продолжать всё труднее. Получится ли сделать следующий шаг?

“Шёл с косой косой косой косой косой косой косой”.

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

“Шёл с косой косой косой косой косой косой косой косой”.

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

(Заметьте, кстати, что эффект похож на эмбеддинг с навесом из другой записки.)

Добавил на страницу “Избранное” ещё пять записок:

• Секунды и физика их подсчёта
• Навязывание геолокации и сети приёмников
• Шумерские цифры и древняя система счисления с плавающей точкой
• Пути самурая и абстракция отсутствия цели
• Математика бэкдора в Dual EC DRBG

C доверенными TLS-сертификатами для IP-адресов связан интересный аспект, касающийся проверки права управления адресом. Так как через DNS проверять право управления IP-адресом нельзя, то проверка проводится путём отправки запроса и получения ответа непосредственно и только по IP-адресу, для которого запрашивается сертификат. Конечно, нельзя забывать, что в IP-сетях всегда фактический обмен данными происходит по IP-адресам. Вот только, в зависимости от схемы проверки, разными могут быть и задействованные адреса, и физические узлы, которые адресам соответствуют. Но в схеме с подтверждением IP-адреса – адрес один, по определению. При этом свойство сети таково, что по заданному IP-адресу может ответить практически любой промежуточный узел – то есть, вовсе не тот узел, которому, как ожидается, предназначен пакет с запросом. В Интернете промежуточные узлы есть почти всегда, обычно – их много.

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

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

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

Естественно, нетрудно заметить, что при HTTP-проверке промежуточный узел точно так же может подтвердить право управления и для DNS-имени, перехватив HTTP. Запросы всё равно ведь отправляются по IP-сети. Так что, если промежуточный узел умеет перехватывать HTTP-трафик, адресованный IP-узлу под проверяемым DNS-именем, то схема подмены не будет отличаться. Более того, сертификат по такой схеме будет получен для доменного имени, а это означает, что перехватывать трафик в дальнейшем, используя подменный сертификат, можно уже с другими IP-адресами. Перехват же с “IP-адресным” сертификатом – потребует продолжения подмены/перехвата части IP-маршута. Другое дело, что так как для поиска IP-адреса в случае HTTP-проверки для DNS-имени УЦ должен использовать DNS, то есть слабая надежда на то, что можно воспользоваться дополнительными мерами защиты: например, CAA-записью.

А вот проверка через DNS, то есть, с размещением кода подтверждения в DNS, – отличается. Здесь перехватывать и подменять уже нужно DNS-ответы, а они, скорее всего, проходят через другие промежуточные узлы. В идеале, для доставки кодов подтверждения через DNS используется несколько совсем разных маршрутов. Более того, если используется DNSSEC, то такая подмена DNS вообще не сработает.

Поэтому “проверка по IP”, в каком-то смысле, играет по собственным правилам, иногда оказываясь довольно слабой.

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

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

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

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

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

Особенности естественного языка, позволяющие оборачивать отсутствие элементов в пустом множестве в размытое значение слова “ничего”, создают тем самым возможность для построения разных силлогизмов из пустого множества. Наверное, самый известный из них – про бутерброд (в вольном переводе): “Что лучше, чем вечное счастье? Ничего! Однако, один бутерброд – заведомо лучше, чем ничего. Следовательно – бутерброд лучше вечного счастья” (R. Smullyan/D. Darling). Здесь, естественно, объяснение в том, что в первой части описывается отсутствие объектов, которые лучше данного: таких объектов, утверждается, пустое множество; а потом, на бутербродном шаге, сравнение производится в обратную сторону: бутерброд заведомо лучше состояния, когда бутерброда нет (не отсутствия объектов, а самого пустого множества). То есть, это разные операции, но то, что пустое множество всего одно, позволяет подменять одну операцию другой.

Например, мне однажды переслали распечатку пары значений вывода утилиты sha256sum, на вход которой подавался результат работы модуля ec из пакета openssl (через “пайп” в консоли). При этом в openssl направлялись два разных файла. Утверждалось, что эти два входных файла содержат одинаковые данные, но только записаны данные в разной форме. Почему? Потому, что равны результаты sha256sum от выдачи openssl. Значения sha256sum, действительно, были равны, несмотря на то, что в openssl передавались разные файлы с разными именами.

Что же произошло на самом деле? Вот что. Утилита sha256sum считает значение хеш-функции SHA-256 от входных данных. Здесь на вход sha256sum поступал вывод openssl ec. Но, ещё раз, если значения равны, то, видимо, тогда и входные файлы содержат одинаковые данные? Нет – одинаковым тут является вывод openssl ec: дело в том, что оба входных файла имели неверный формат, поэтому модуль ec не мог их разобрать и печатал сообщение об ошибке, однако в стандартный вывод – писал пустое множество байтов; то есть, ничего не писал, проще говоря. А значения SHA-256 совпали потому, что на вход хеш-функции поступило пустое множество. А оно – одинаковое, вне зависимости от того, как именно сломался каждый из входных файлов.

Множества, состоящие из элементов разных типов, могут не сочетаться по типам, но пустое множество – сочетается со всеми типами. Когда нет апельсинов и ананасов, шестерней и транзисторов – то, с одной стороны, нет вещей разных типов, но, с другой стороны, общим тут является то, что их нет. Это сплошь и рядом используется в языках программирования.

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

Современное обозначение для пустого множества – ∅ – появилось относительно недавно, в 30-х годах прошлого века. Но вполне возможно, что саму концепцию систематическим образом впервые строил Джордж Буль, в 1847 году. Впрочем, соответствующая концепция у Буля относится к логике и больше похожа на противопоставление “ничего” – которое есть “нуль”, 0, – “всему”, единице, 1.

Есть более интересное развитие определения: через количество объектов, которые не “само-эквивалентны” (Готлоб Фреге). Здесь “само-эквивалентность” – это обобщение свойства рефлексивности, то есть, когда A = A по свойствам операции, а именно, каждый объект эквивалентен самому себе. Тогда пустое множество – это те объекты, которые не эквивалентны самим себе. Казалось бы – таких объектов просто нет. Но чтобы заявить о том, что чего-то нет, придётся определить это “что-то”, чтобы описать и проотрицать существование, и на этом пути магу легко попасть в ловушку: попытка определения того, чего нет, введение типов, может вызвать данный “зомби-объект” к существованию – он, внезапно, “станет быть” или “будет есть” – как там правильно? А вот способ “не-само-эквивалентных” объектов – позволяет выполнить такое определение без излишней типизации и “зомби”. Ну, в каких-то пределах. Так, в DNSSEC подписывается цифровой подписью факт отсутствия записи – делается это при помощи погружения “отсутствия” в искусственный “пустой интервал” между соседними существующими DNS-записями, иногда такое погружение происходит замысловатым образом.

Не так уж редко используется и свойство пустого множества быть невозможным событием. Как известно, вероятность невозможного события, в каком-то смысле, сильнее нуля – ведь если рассуждать в классическом сеттинге, с действительными числами, то событие с нулевой вероятностью – может произойти. Например, если вы бросаете безразмерную точку на действительную окружность, то вероятность попасть в любое конкретное действительное число тождественно равна нулю, но в какое-то число вы всегда попадёте. Другое дело, что точно записать такие попадания – не выйдет, потому что нельзя записать точно большинство действительных чисел.

Одно и то же пустое множество можно помещать в разные коробки, получая разные пустые коробки. А пустая коробка может служить существенным признаком. Посмотрим на CAA-записи в DNS. Интерпретация этих записей отличается в случае, когда запись есть, но её значение – пустая строка, и в случае, когда нет самой CAA-записи. Здесь буквально проявляется эффект, позволяющий строить натуральные числа из пустого множества: когда нет CAA-записи – это настоящий нуль, пустое множество; когда CAA-запись есть, но она пустая – это уже единица, потому что возможна только одна пустая CAA-запись (ну или так: все пустые CAA-записи – одинаковые). То есть, тут, с одной стороны, играет роль определение того, чего нет: “нет значения CAA-записи” против “нет самой CAA-записи”; с другой стороны – содержательный эффект возникает из погружения пустого множества в большую структуру. Это, в точности, процесс (∅=0, {∅}=1).

Процесс погружения ∅ в {} даёт основной инструмент для генерирования множеств. Фигурные скобки обозначают операцию “множество из (элементов)” (set of). Так, {∅} – это множество из одного элемента, пустого множества. При этом одноэлементное множество (singleton, синглетон) – это не то же самое, что один этот элемент. То есть, заметьте, что {} и {∅} (или, если хотите, {{}}) – сильно разные вещи. Если, борясь за логическую стройность, ввести дополнительно понятие “класса”, как способа избежать возникновения абсурдного “множества всех множеств”, то пересечение всех классов – это и будет пустое множество. Именно поэтому в английском, например, языке пустое множество правильно обозначать как the empty set, с определённым артиклем the, а не an empty set. “A set”, но “the empty set”.

Данное важное свойство закреплено, – обычно!, – и в современных языках программирования высокого уровня. Если написать, что var a := {1} (то есть, переменная a – это массив из одной целой единицы по определению), то станет верным, что 1 != a (то есть, одна целая единица не равна массиву, состоящему из одной целой единицы).

А если взять JavaScript, то можно наблюдать сразу несколько особенностей интерпретации пустого множества и “ссылок” на пустое множество в программировании:

const set = new Set();
const object = {};

set.add(1);
set.add("two");
set.add(object);
set.add(object);
set.add({});

console.log(set.size);
for (const item of set.keys()) { 
  console.log(item);
}

– эта программа напечатает вот что:

4
1
two
Object {  }
Object {  }

– ничего странного, но довольно показательно.

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

Пустое множество – аксиоматично. Так, чрезвычайно часто встречающийся в популярной литературе феномен, известный как “набор аксиом теории множеств” ZFC, буквально содержит аксиому о пустом множестве: “существует пустое множество”. Пустое тут – это то, в котором нет элементов, но оно – множество: то есть, множество, к которому не принадлежит ни один элемент. Получается, “пустота” множества может выступать как предикат: “[A] есть пустое”, и без пустого множества построение логических теорий становится затруднительным.

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

никто: [%blah-blah-blah%]
иванов: подпрыгивает на батуте

– тут совсем условные обозначения, конечно: “[%blah-blah-blah%]” – пустое, “батут” – содержание. Главное – схема: “никто: {}, кто-то: {предмет мема}”. “Когда никто не догадался, кроме Иванова”.

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

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

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

Опубликовал всё же на “Хабре” статью про уравнение Бомбелли и “минусы под радикалами” (отчасти – по мотивам предыдущей записки). Это девятнадцатая опубликованная статья, так что теперь таки стало 19 статей, 11 постов и 3 новости.

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

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

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

Если взять то самое знаменитое √(-121), из труда Бомбелли, то это не есть действительное число, ведь оно не является ни отрицательным, ни положительным, ни нулём. Почему ни отрицательным, ни положительным? По тому самому порядку, который описан выше: отрицательное – это меньше нуля; положительное – это когда нуль меньше числа. Почему не является нулём? Потому что иначе “схлопывается” вся арифметика: должно быть 2 + √(-121) = 2. Но раз нет подходящего отношения порядка, то нет и отрицательных/положительных. Это всё отмечено у Бомбелли – буквально, он пишет, что “такой радикал не может быть назван ни положительным, ни отрицательным”. В его “Алгебре” это означало, что у значения вида √(-121) есть особенная сигнатура, а поэтому нужно ввести дополнительную операцию по работе с этой сигнатурой, что в истории математики и принято называть изобретением “мнимой единицы”.

Посмотрим на ситуацию чуть более детально, пусть и не совсем строго. Положим, что обычные “плюсы” и “минусы” – это +1 и -1, а “необычные”, комплексные, это +i и -i. Мы получили кортеж значений: {+1, -1, +i, -i}. Попробуем ввести привычное отношение порядка, сохраняющее “естественную” арифметику. Предположим, что -i < 0 (отрицательное), а +i > 0 (положительное). Тогда (+i)*(+i) должно быть положительным, больше нуля.

Однако, согласно свойствами мнимой единицы, (+i)*(+i) = -1 – именно это и позволяет выносить сигнатуру из-под знака радикала: √(-121) = (+i)*11. Получается, что -1 > 0, то есть, -1 – положительное? Но тогда -i = (+i)*(-1) должно быть тоже положительным, ведь мы и приняли, что +i – положительное, и нашли, что -1 – тоже положительное. Следовательно, уже из соображений симметрии, +1 – отрицательное, то есть, +1 < 0. Странно, не так ли? Более того, +i – тоже отрицательное. Но мы ведь приняли, что +i – положительное? Противоречие. Поэтому-то ввести тут привычные отрицательные и положительные числа, но с сигнатурой i, не получится. Не получится и построить отношение линейного порядка “с арифметикой” на комплексных числах. Это ещё одно доказательство того, что никаких квадратных корней из отрицательных чисел быть не может – нарушится логика построения числовых структур.

Что же это за √(-121)? Что получается, если “возвести его в квадрат”? √(-121) – это комплексное число. Когда вы его возводите в квадрат, то тоже получаете комплексное число: -121 + i*0. То, что мнимая часть здесь “умножена на ноль”, вообще говоря, не делает число автоматически действительным. Потому что базовая операция умножения проводилась в комплексных, её результат – комплексное число, поэтому -121 = -121 + i*0 – комплексное. Тут всегда пары значений. А “забыть о комплексных” – это уже дополнительная операция, которая позволяет сопоставить некоторые комплексные числа – действительным (не парам действительных, заметьте!); операция, так сказать, позволяет спустить некоторые комплексные – в действительные. Да, эта операция регулярно подразумевается. Отсюда и надуманная “противоречивость”, из которой стало модно делать кричащие, но ложные, утверждения: мол, “можно” извлечь квадратный корень из отрицательного числа, но “вам об этом не говорят”. Напоминает историю со школьной задачей про ящики и апельсины.

В Let’s Encrypt собираются внедрить (англ.) новый метод проверки права управления доменом (DCV), который, при помощи публикации специальной TXT-записи, привязывает DNS-зону к ACME-аккаунту, а не к коду валидации, и при этом такая привязка становится “постоянной” – видимо, с точностью до того, как сервер будет запрашивать TXT-записи и фиксировать факт удаления соответствующего кода. Метод называется DNS-PERSIST-01.

Довольно занятное начинание. Например, в описании от Let’s Encrypt (по ссылке выше) имеется пространная “мотивировочная часть”, где несколько раз утверждается, что, мол, “во многих конфигурациях реквизиты доступа к DNS API распределяются через “пайплайны” выпуска и обновления [сертификатов], увеличивая количество мест, в которых атакующий может их [реквизиты] скомпрометировать”. Так, конечно, делать нельзя – нельзя раздавать реквизиты доступа к DNS “пайплайнами” по многим местам – ACME этого не требует. Но забавный момент тут в другом: предлагаемая схема, предположим, уходит от “раздачи реквизитов” от DNS, но зато привязывает всю защиту и безопасность к ключу от ACME-аккаунта!

То есть, ACME-аккаунт в этой схеме строго привязывается к DNS-имени, поэтому, если атакующая сторона получила доступ к ACME-аккаунту, то доступ к DNS уже вообще не нужен. Многие ли DevOps и системные администраторы вообще знают, что в ACME-клиенте есть секретный ключ от аккаунта, которым подписываются запросы, и о том, где этот ключ хранится? Не раздаётся ли этот ключ через “пайплайны” по резервным копиям? Вопросы, впрочем, риторические. Но должно же быть очевидно, что замена одной потенциальной “точки взлома” (доступы к DNS) на единственную другую (ACME-ключ клиента) – не даёт каких-то новых преимуществ с точки зрения безопасности. Но нет – приводят в пример. (Все эти моменты, кстати, описаны в черновике RFC для DNS-PERSIST-01. Но это – и черновик, и вряд ли многие прочитают.)

ACME-аккаунт – контролируется УЦ; можно предположить, что это не важно – УЦ и так выпускает какие хочет сертификаты; однако на практике, если используется одноразовый код подтверждения через DNS, есть небольшая надежда, что модуль проверки права управления доменом – как-то отвязан от модуля авторизации ACME-запросов; в случае же нового варианта – достаточно контроля над обработкой ACME-запросов.

И если, на практике, на стороне, которая заказывает TLS-сертификаты, управление DNS ещё как-то понятно администраторам, то ACME-клиент – совсем мутная вода.

Естественно, для того, чтобы публиковать коды ACME-подтверждения в DNS, не требуется раздавать реквизиты от этой DNS по куче мест. То есть, понятно, что такое регулярно происходит на практике, тут у Let’s Encrypt всё верно написано: это, как раз, один из побочных эффектов всей этой “автоматической истории” с ACME – раскидывание CNAME и тому подобные нехорошие варианты. Но управление DNS проще реализовать правильно и надёжно, чем управление ACME-клиентом: например, машина, которая является источником обновлений DNS-зоны, может сама ходить за кодами на точку раздачи, подтверждая потом публикацию ACME-клиенту, и так далее – вариантов много. В теории, наверное, и для ACME-ключа можно придумать серьёзную защиту. Проблема тут совсем в другом: многие знают, что DNS нужно защищать, а то будут проблемы; о том, что защищать нужно ACME-аккаунт – ну, может, кто-то и подумал, но даже если и подумал, то, скорее всего, решил: “а зачем? всё равно же DNS-доступ нужен для выпуска сертификата”. И не забывайте, что доступ к DNS, действительно, всё так же позволяет выпустить TLS-сертификат, только теперь ещё и доступа только к ACME-аккаунту становится достаточно.

Кстати, про схемы генерирования криптографических параметров и при чём здесь NUMS (Nothing Up My Sleeve – “Ничего в моём рукаве”). Опасения всегда связаны вот с чем: предположим, что сильный атакующий разработал специальные “секретные теоремы высшей алгебры” и, например, может эффективно взламывать асимметричные криптосистемы для чисел специального вида, но какой там “вид” – это секрет. Те, кто “секретные теоремы” ещё не узнал, взламывать не могут. Но чтобы схема работала, стандартные параметры должны состоять из тех самых чисел специального вида. (Конечно, схема имеет фундаментальную проблему: как только “секретные теоремы” перстают быть “секретными” – криптосистема ломается для всех. С одной стороны – это очень плохо. С другой стороны – сейчас уже обстановка достаточно странная для того, чтобы подумать: “кому какая разница? просто возьмите другую криптосистему”.)

Использование специальных параметров, если они подобраны хорошо и в соответствии с математикой криптосистемы, – это не обязательно бэкдор в самой криптосистеме, как ни странно. Дело в том, что и так есть много требований к выбору параметров, чтобы эти параметры были стойкими. Например, в “мультипликативном” варианте протокола Диффи-Хеллмана модуль P должен быть простым числом, но таким, что (P-1)/2 – тоже простое число. Или, для классических схем на эллиптических кривых, с дискретным логарифмом, нельзя выбирать кривые определённого вида, например, суперсингулярные с малой степенью вложения. И так далее, и тому подобное: есть много требований к RSA, есть требования к ML-DSA и пр. Начать с того, что элементарное требование на минимальную битовую длину записи – это требование к стойкости числового параметра, которое является универсальным и для симметричных, и для асимметричных криптосистем. Другими словами – у конкретных реализаций криптосистем есть типовые параметры, эти параметры должны быть выбраны так, чтобы не было “сомнений в добрых намерениях”. “Специальный” же вид – лишь добавляет “секретное” свойство, которое прямо в требованиях не указано.

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

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

Конечно, существуют сложные детерминированные схемы с хеш-функциями, цифровыми подписями, доказательствами с нулевым разглашением и заголовками новостей в газетах, взятыми на день генерации параметров по модулю вершины блокчейна биткойнов. Но это именно что сложные схемы. А вот в упоминавшемся недавно RFC 7919 – описана простая схема получения неслучайных и надёжных простых чисел. В этой схеме используется запись числа e (основание натурального логарифма). Чем такая схема хороша?

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

Во-вторых, имеющаяся публичная структура (см. формулу с e) гарантирует, – в какой-то мере, конечно, – что число нельзя снабдить другой, скрытой произвольной структурой. Естественно, строго гарантировать тут можно то, что выдача алгоритма вычисления e не была приспособлена под требования закладки, но не обратное – требования закладки, всё же, можно приспособить под запись константы e. То есть, такую вторичную структуру нужно будет согласовать с уже имеющимся алгоритмом. Это, скорее всего, возможно проделать, но всё равно – какая-то фантастика. Если уж допускать такие возможности по созданию закладок в параметрах, то что тогда вообще помешает реализовать закладку любым другим теоретическим способом?

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

В копилку примеров реального использования ИИ/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.