Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Кстати, что касается URL (URI), как носителя “секрета”, установленного в составе адреса документа или параметров URL: ещё в 2015 году, десять лет назад, “Яндекс.Браузер” собирал URL, которые посещает пользователь, и отправлял их поисковому роботу “Яндекса”, чтобы тот индексировал контент для всех пользователей поисковой системы (этот подход сильно напоминает теперешнее “обучение ИИ”, кстати). Так что, полагаясь на “секретность” URL (что само по себе очень плохо), браузеры-то как-то неправильно вычёркивать из перечня каналов утечки. Браузер исполняет веб-интерфейс, а не пользователь “на бумажке”, так что URL могут уходить куда угодно именно потому, что это URL.
Заметьте, что URL – это не авторизационный куки-файл, который браузеру тоже известен, но который передаётся в составе заголовков HTTP-запроса, поэтому чётко отделяется в любом браузере от URL, и браузер, всё же, этот файл будет пытаться отправлять только тем узлам, которым он прямо предназначен (на сей счёт есть очень много спецификаций и требований, а про URL – подобных требований нет).
Комментировать »
Известная шутка гласит, что категорий людей – 10: одни уже знают двоичную систему счисления, а другие – ещё нет. Занятно, что 102 обозначает простое число – два. Это большая редкость в системах счисления, которые рутиннно используются в ИТ. Понятно, что ни в восьмеричной, ни в десятичной, ни в шестнадцатеричной, 10 (как запись) не может обозначать простое число (как и всякая запись, заканчивающаяся на 0). А в двоичной – пожалуйста.
Естественно, это возможно только потому, что основание двоичной системы – простое число два. Если взять любое другое простое основание, то 10 тоже будет простым, потому что это и есть запись основания: три – по основанию 3, пять – по основанию 5, семь – 7, и так далее. Но наиболее привычны, кроме десятичной (десятеричной), это двоичная, восьмеричная и шестнадцатеричная.
Возьмём запись 11. В двоичной – это простое число три (112 = 2 + 1 = 3). В восьмеричной – девять, составное, но квадрат простого: 3^2. Та же запись 11 означает одиннадцать в десятичной, простое. Шестнадцатеричное 11 – это семнадцать, тоже простое.
Использование в этом ряду двоичной системы ограничивает доступный набор цифр: только 0 и 1. Но можно взять, например, 101 – трёхзначное:
это пять в двоичной (простое);
шестьдесят пять – в восьмеричной, составное: пять на тринадцать;
сто один – в десятичной, простое;
двести пятьдесят семь – в шестнадцатеричной, простое.
Обратите внимание, что запись чисел словами – это инвариантная, относительно системы счисления, запись.
1112 = семь (простое);
1118 = семьдесят пять (составное);
11110 = сто одиннадцать (простое);
11116 = двести семьдесят три (составное: 3*7*D).
Не забывая о том, что все простые числа, кроме числа два и числа три, имеют вид 6*n +/- 1, на трёх цифрах можно и остановиться. Тем более, что шестеричная система счисления не является распространённой.
Комментировать »
В продолжение записки о том, что появится новый тип УЦ (Удостоверяющих Центров) для выпуска TLS-сертификатов, базирующихся на хеш-деревьях (деревьях Меркла). Речь в этой заметке не про технические детали (про них, возможно, будет отдельно в другой заметке), а про изменение технологических и административных подходов в работе УЦ, которые с новым подходом связаны. Сейчас пока что всё существует в виде тестов и черновиков RFC, но можно ожидать быстрого перехода УЦ на описанную схему. Примерно так же, как было с внедрением обязательных SCT-меток (от логов Cetrificate Transparency) в сертификаты: браузеры начинают верить только в сертификаты с правильными SCT-метками – УЦ для веба вынуждены подстроиться.
Новая схема работы радикально переиначивает логику деятельности УЦ. Дело в том, что полностью меняется фундаментальный процесс: УЦ должны вести собственный лог сертификатов, который становится необходимым источником сертификатов. Да, именно так. Потому что сертификаты, в новой схеме, образуются в результате корректного ведения лога. Это весьма существенное изменение: фактически, то, что сейчас реализуется Certificate Transparency, заносится внутрь УЦ и становится строго первичным, фундаментальным процессом.
Сейчас набор технологий и сервисов, который называется Certificate Transparency, реализуется внешним, относительно деятельности УЦ по выпуску сертификатов, образом. В новом варианте, при штатной работе, УЦ не сможет выпустить сертификат, не внеся прежде соответствующие записи в свой лог сертификатов и не получив на этих изменениях подписей от третьих сторон – эти третьи стороны выступают гарантами всего процесса, их подписи – необходимы для валидации сертификата.
Собственный лог УЦ как раз и ведётся в форме хеш-дерева. В сертификат нового типа обязательно должны быть добавлены артефакты из лога (доказательство включения в дерево), что и ставит внесение записей в лог выше процесса выпуска сертификата.
Да, сейчас УЦ должны получать SCT-метки с подписями логов Certificate Transparency (CT), чтобы внести эти метки в сертификат. То есть, процесс выпуска сертификата уже завязан на те или иные CT-логи, что, конечно, делает его похожим на предлагаемый новый вариант. Однако в новом варианте есть целых три существенных отличия:
1) УЦ обязательно ведёт свой лог, который необходим для формирования сертификатов (но это не отменяет других логов);
2) вводится два типа сертификатов, и даже в “полный” сертификат включаются сведения из лога, с подписями нескольких строн, а не просто подпись УЦ на конкретных данных (как сейчас);
3) основной метод оптимизации – сертификаты без подписи, которые содержат только доказательства включения в лог.
И вот главное из этих трёх нововведений – это сертификаты без подписи (“бесподписные”).
Почему весь смысл в сертификатах без подписи? Потому что только такие сертификаты позволяют отказаться от больших подписей криптосистем с постквантовой стойкостью. В этом смысл оптимизации. Да, тут нетрудно заметить ещё один занятный момент: речь про ML-DSA, а там, действительно, подпись занимает несколько килобайтов; казалось бы, и квантовые компьютеры выглядят теоретическим построением, и никто не доказал, что большой размер подписи является необходимым условием постквантовой стойкости – тем не менее, именно многокилобайтные подписи оказываются существенным фактором внедрения сертификатов без подписи и новой схемы работы УЦ. Впрочем, необходимо отметить и то, что схема с хеш-деревьями позволяет существенно экономить трафик уже и для RSA-подписей (с разрядностью 4096 бит и больше).
Чтобы работать с сертификатами без подписи, чтобы валидировать их, нужны свежие копии узлов доверенных деревьев (поддеревьев, если точнее), которые покрывают эти сертификаты. То есть, получается, что валидирующая сторона (браузер, предположим) будет достаточно часто скачивать обновления деревьев для валидации сертификатов. И если обновление получить не удалось, то сертификат без подписи будет считаться невалидным. Но, естественно, можно использовать “полный сертификат”. (Тут ещё есть отдельная история про то, как с новой схемой соотносится отзыв сертификатов, но её оставим для другой записки.)
Узел, запрашивающий выпуск нового сертификата у УЦ, может получить практически сразу же “полный сертификат” и, с некоторой задержкой, оптимизированный сертификат без подписей. Соответственно, TLS-сервер, при установлении TLS-соединения, мог бы выбирать, какой сертификат отправить клиенту, в зависимости от сигналов в начальном сообщении клиента. В TLS планируется добавить расширения, которые позволят информировать сервер о списке доверенных состояний деревьев (логов), которые известны клиенту. Так что, если сервер видит, что клиент не сможет валидировать оптимизированный сертификат (без подписей), то сервер присылает полный сертификат.
Понятно, что если сертификат полный, то нет ни экономии трафика, ни экономии вычислительных затрат на проверку подписей – то есть, довольно сомнительная затея: поэтому, конечно, основной расчёт на то, что большинство клиентов (веб-браузеры) будут оперативно обновлять списки доверия, скачивая их из каких-то точек раздачи, и принимать “бесподписные” сертификаты при соединении с веб-узлами. Получаем привязку к новой технологии и её провайдерам, в форме токенов доступа: если ваш клиент вдруг отстал от обновления дереьвев, то, как минимум, приходят “медленные” большие сертификаты, а как максимум – невозможно штатно заходить на веб-сайты и подключаться к TLS-узлам, потому что они все перешли исключительно на “бесподписные” сертификаты, в целях оптимизации. Если сейчас нужная для валидации информация, кроме статуса отзыва, есть в самом сертификате, то с “бесподписными” сертификатами – это окажется совсем не так.
То есть, в схеме с хеш-деревом и “бесподписными” сертификатами нужно регулярно скачивать обновления хеш-дерева. Заметьте, кстати, что TLS-расширение с поддерживаемым списком – может использоваться для профилирования и распознавания клиентского ПО по составу трафика. Хуже того, если забанят доступ к точкам раздачи обновлений хеш-деревьев, то перестанут работать веб-сайты с “бесподписными” сертификатами, и обойтись отключением “онлайн-проверки” статуса, как в случае с OCSP, уже не выйдет.
Комментировать »
В Google планируют уже в следующем году начать строить в браузере новую инфраструктуру УЦ для TLS, используя схему с доказательствами на деревьях Меркла (хеш-деревьях) в оконечных сертификатах.
Это, технически, совсем другая история, по сравнению с действующими сейчас способами выпуска и публикации TLS-сертификатов. Доказательства принадлежности к дереву используются вместо подписи в сертификате. Это, фактически, перенос технических идей Certificate Transparency внутрь самих сертификатов. Я писал об этом новом подходе не так давно. С одной стороны – довольно интересная, изящная технология. С другой стороны – тут просматривается ещё большая технологическая привязка к тому же Google (потому что нужен будет совместимый TLS-стек в браузере, а реализовать такие технологии независимо – мало кому сейчас по силам; посмотрите хоть бы на внедрение ACME: там практически везде “готовые библиотеки/скрипты”, на обоих концах, что называется – мало кто понимает, как работает, но все используют и встраивают в свои системы на правах “чёрного ящика”). Но интересно, факт.
Основное обоснование для внедрения этой новой схемы – использование криптосистем электронной подписи с заявленной постквантовой стойкостью: в таких криптосистемах, обычно, очень длинные подписи (это, естественно, не является обязательным требованием для постквантовой стойкости, но реальность такова – сейчас предлагаются очень длинные и ключи, и подписи). Использование доказательств включения в хеш-дерево вместо подписи – сильно сокращает количество байтов, нужное для записи: доказательства строятся на хеш-функциях, а их выдача достаточно короткая.
В сообщении Google (по ссылке выше) есть ещё интересный момент: там пишут, что к концу этого года ожидают (возможно, в Chrome/Chromium) поддержку X.509-сертификатов с “обычными” “постквантовыми подписями” для непубличных PKI (для УЦ, которые не входят в “коробочный” список доверия браузера). То есть, в браузере может появиться поддержка криптосистем подписи с постквантовой стойкостью в сертификатах. Это довольно занятно, так как позволит использовать такие сертификаты хоть в каких-то браузерах. (Но это ещё нужно посмотреть, что там реально будет.)
Комментировать »
Сейчас практически постоянно пишут и говорят про “ИИ в математике”. Типа, какие “достижения”. Понятно, что инструмент перебора – может доставать какие-то доказательства кусками из ранее опубликованных работ, “синонимизировать” их, собирать из них другие доказательства и прикреплять к “нерешённым задачам”, например, из списков Эрдёша (где относительно много довольно простых, для специалиста, задач). Такой поиск перебором даже может быть полезен (но по модулю избыточных ресурсов, конечно).
Перебор – перебором, но LLM-перебор – это совсем не тот перебор, который вполне себе является методом математического доказательства. Например, как метод доказательства, перебор позволяет быстро находить контрпримеры к каким-то утверждениям. Элементарная иллюстрация: допустим, кто-то говорит, что нельзя “квадрат разложить на два квадрата”; это легко опровергнуть, просто “подобрав” самую известную пифагорову тройку: 3^2 + 4^2 = 5^2. Естественно, компьютеры существенно улучшили возможности по перебору: несравнимы возможности современного ПК и даже таких признанных вычислителей, каким был Эйлер. Однако всё это без учёта новомодных LLM, в которых, похоже, вычислительный ресурс в основном расходуется впустую.
А вот насколько точны результаты компьютерной обработки, применительно к теоретической математике, и как их интерпретировать – вопрос довольно сложный, скорее философский. По крайней мере, проблемы возникают с действительными числами, которые для компьютеров недоступны в принципе. Хуже того, несмотря на большую мощность, компьютер в принципе не может заглянуть даже в область действительно больших натуральных чисел. Но это всё сложные моменты, которые ничуть не отменяют того факта, что компьютеры давно влияют на теоретическую математику. И дело тут ни разу не в модных LLM.
Вообще, интересующимся темой, я бы порекомендовал серию прекрасных статей Н. А. Вавилова, которая начала выходить ещё в 2020 году, до всего этого “хайпа” с LLM “в математике”, и к LLM никакого отношения не имеет: “Компьютер как новая реальность математики” – вот где действительно есть тематическое содержание.
Комментировать »
Лексический контекст может трансформировать семантику одного и того же слова занятным образом. Особенно, в русском языке. Особенно, если графически – это одно и то же слово. Есть хорошо известный, но всё равно интересный, пример – он про “косых косых”.
“Шёл с косой косой косой”.
Что здесь написано? Например, это сказочный заяц (косой или Косой), который идёт, неся на плече ручной инструмент для покоса травы, но этот инструмент довольно кривой: “коса у зайца на плече косая”.
Теперь допишем ещё одно слово “косой”.
“Шёл с косой косой косой косой”.
Что получилось? Теперь заяц-косой ещё и реально косой – то есть, у него большие проблемы с глазами.
“Шёл с косой косой косой косой косой”.
Заяц, который несёт на плече косую косу, идёт вдоль песчаной косы: спустившись с холма, вышел заяц к реке, да закинул косу на плечо, шагая привычной дорогой – вдоль песчаной косы. Что ж, пока заяц идёт, продолжаем приписывать слово “косой”.
“Шёл с косой косой косой косой косой косой”.
Предположим, что и песчаная коса – тоже косая, на то она и коса. Продолжать всё труднее. Получится ли сделать следующий шаг?
“Шёл с косой косой косой косой косой косой косой”.
Семь косых. Ну, казалось бы, теперь-то грамматические варианты закончились, а предложение не “парсится” – так? Нет, не закончились. Дело в том, что косой заяц был нетрезв, поэтому он ещё раз косой, но теперь – в смысле общего состояния сознания: мысли зайца запутаны, но кажутся ему строгими и прямыми, не то что косая коса, которую несёт он на плече. Интересно, что “косой”, в значении не трезвый, можно в этом предложении переставлять на разные экземпляры графического представления слова “косой”.
“Шёл с косой косой косой косой косой косой косой косой”.
Восемь косых – и вот тут уже не обойтись без дефисов, потому что иначе структура не вписывается ни в какой грамматический вариант. Зато с дефисами – вписывается: “Шёл с косой-косой косой косой косой-косой косой косой”. То есть, коса у зайца теперь очень сильно косая: косая-косая. Сам заяц теперь настолько нетрезв, что таких нетрезвых зайцев поди ещё найди: косой-косой. Но с дефисами эффект не такой интересный, поэтому останавливаемся на восьмом уровне.
(Заметьте, кстати, что эффект похож на эмбеддинг с навесом из другой записки.)
Комментарии (1) »
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; надеюсь, что его всё же не доломают окончательно – браузеров и так почти не осталось.)
Комментарии (2) »
Пустое множество принадлежит к набору фундаментальных объектов современной математики. И не только математики: в чистой философии – значение пустого множества едва ли не выше. Поэтому-то постоянно множатся и роли, которые пустое множество играет в куда более прикладных областях, чем теоретическая математика и философия: в информационных технологиях, да и в технике вообще.
Главное свойство пустого множества в том, что такое множество – единственно. То есть, у нас могут быть множества, собранные из разных объектов, но пустое множество – всегда одинаковое. Более того – это одно и то же множество, вне зависмости от “объектов” и типов. Пустое множество ананасов совпадает с пустым множеством апельсинов по слишком многим характеристикам, чтобы считать, что множества ананасов и апельсинов “пусты” разным образом, как и множество фруктов вообще.
Но, конечно, полностью отказаться от того, что “существуют” и пустое множество апельсинов, и пустое множество ананасов – довольно трудно: вот, только что была введена некоторая различительная окраска – ананасы против апельсинов. Например, если для приготовления блюда требуется ананас, то отсутствие апельсина – никак на кулинарную ситуацию не влияет, тогда как нехватка ананаса делает приготовление невозможным. Однако пустота тут, как концепция, общая. Да, нужно различить понятия “пустота” (“тип”) и “быть пустым” (“стрелка”), но стоит поднять пустоту в ничто, как начинает играть тот фактор, что и ничто, в представлении, бывает белое и чёрное.
Особенности естественного языка, позволяющие оборачивать отсутствие элементов в пустом множестве в размытое значение слова “ничего”, создают тем самым возможность для построения разных силлогизмов из пустого множества. Наверное, самый известный из них – про бутерброд (в вольном переводе): “Что лучше, чем вечное счастье? Ничего! Однако, один бутерброд – заведомо лучше, чем ничего. Следовательно – бутерброд лучше вечного счастья” (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%]” – пустое, “батут” – содержание. Главное – схема: “никто: {}, кто-то: {предмет мема}”. “Когда никто не догадался, кроме Иванова”.
Комментировать »
Кратко этот сайт характеризуется так: здесь можно узнать про технологический прогресс, Интернет, математику, криптографию, авиацию, компьютеры, авиационные компьютеры, вооружения, роботов, вооружение роботов, армии мира, астрономию, космические исследования. И иногда о чём-то ещё (