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

Беспроводной телефон, использующий свет (солнечный) в качестве носителя сигнала, а нехитрую систему зеркал – в качестве модулирующей схемы. Из 1880 года, тоже от Белла. См. иллюстрацию.

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

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

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

Конечно, нельзя сказать, что и учтеки исключены, и помехи не сработают. Что касается утечек, то принимать можно какие-нибудь блики, возникающие при работе передатчика. Впрочем, для 1880 года это довольно сложно – слишком высокая чувствительность потребуется.

Скопирую сюда своё сообщение с “Хабра”:

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки – шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS – есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз – для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify – TLS-сессия браузером установлена не будет.

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

Недавно опубликовано очередное сочинение-опус про AI/ИИ и кардинальные изменения в статусе цивизизации к 2030 году: AI 2027 (англ., много букв). Пусть вас не обманывает 2027 в названии – самые радикальные прогнозы там, как сейчас принято, даны на 2030, а в 2027 году только ожидается деятельный суперинтеллект (это, впрочем, менее двух лет осталось ждать).

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

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

Развитой же ИИ-агент, как сообщают, “знает больше фактов, чем любой человек, знает практически каждый язык программирования и может решать хорошо поставленные (well-specified) задачи чрезвычайно быстро”. Вообще, что касается задач, то акцент тут нужно бы сделать на “хорошо поставленных”, вспомнив методы автоматического генерирования кода по формальному описанию алгоритма – но, видимо, эти достижения теперь относят к другой области. А что означает “знает язык программирования”? Способность генерировать код – не является достаточным условием для оценки уровня “знает язык”. Эти тонкости не принято определять в текстах про сверхразумный AI.

Впрочем, в тексте AI 2027 некоторые “оценочные суждения” сопровождаются определениями из серии “Что бы это значило?”. И это странные определения, вполне в духе выдачи условного ChatGPT. Например, объяснение того, что имеется в виду, когда пишут про 50-процентное ускорение разработки ИИ-алгоритмов при использовании ИИ, следующее: “50-процентное ускорение – это означает, что [компания] OpenBrain, используя ИИ, достигает за неделю такого же прогресса в исследовании, как она достигла бы за полторы недели без использования ИИ”. Содержательно, да.

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

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

Типовой уровень исходящего трафика дата-центра указан – это “100 GB/second range”. Видимо, порядка ста гигабайт в секунду, которые гигабайты либо потребляют пользователи ИИ-приложения, разрабатываемого на мощностях дата-центра, либо кто-то попутно реализует DoS-атаку других дата-центров (это догадка, а в тексте про DoS ничего нет).

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

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

Но самое показательное – это концовки данного произведения. Понятно, что под них и писалось всё остальное. AI 2027 предлагает две возможных концовки. Одна из них – уничтожение всех человеков мощным ИИ в 2030 году при помощи “биологического оружия”; ИИ далее модифицирует под свои нужды планету Земля, колонизирует прочее пространство Солнечной системы и далее, за её пределами, силами роботов.

Другая концовка – объединение всех государств мира под управлением США (да), происходящее в результате локальных переворотов, которые ИИ помогает реализовать (так написано); после чего наступает эра процветания (или милосердия?), человеки запускают ракеты, – для колонизации планет Солнечной системы, а не то что вы подумали, – и всё это с помощью хорошего ИИ.

Иных вариантов, кроме этих двух, сочинение-прогноз не предусматривает. С Днём Космонавтики, как говорится.

GPS плохо работает, местами – часы внезапно убежали на две секунды (или около того). В 2012 году я писал на dxdt.ru про гипотетический автоматический прибор-навигатор, который не зависит от спутниковой системы. Вообще, с точки зрения практической навигации, понятие “определения координат”, как таковое, оказывается слишком размытым, потому что основа тут – это привязка к некотороому базису, задающему систему отсчёта, или, если хотите, координатную сетку. И такой базис может быть весьма условным.

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

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

Пираты иногда сходили на берег. Карта сокровищ: сундук зарыт в десяти шагах к северу от развесистого дуба. То есть, главное – найти тот дуб, а дальше уже навигация пойдёт без проблем: отсчитываем десять шагов, хватаем лопаты и – сундук наш. Но это всё только кажется. Для подсчёта расстояния в шагах тоже нужны часы. А как иначе определить длину шага? Конечно, в случае с картой сокровищ необходимость точного времени находится на втором плане. Но если вы измеряете расстояние лазерным дальномером, то часы уже используются прямо, пусть и на очень коротком интервале времени, и не для хранения отсчёта по Гринвичу. Однако дерево и десятки шагов, со скрытым измерением времени, неплохо иллюстрируют тот факт, что главное – правильно выбрать и понимать базис, который подходит для решаемой навигационной задачи. Поэтому-то хорошим источником опорных точек является рельеф местности.

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

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

Рельеф или нет, однако практическая задача состоит в прибытии в заданную точку, но вот только не на карте, а на местности. А кто сказал, что все точки схемы рельефа расставлены без ошибок? И даже если большого количества ошибок в исходной схеме нет, то всё равно осталась погрешность, которая была внесена аппаратурой при построении карты. Это всё равно некоторая модель, и тут есть довольно занятный момент. Построение карты рельефа это одно, а проверка результата – совсем другое: для проверки нужно каким-то образом подобрать независимый, но совместимый, базис. Другими словами: пусть карта рельефа получена, но чтобы понять, что она пригодна для решения практических задач, нужно определить какие-то тестовые пути с известными координатами. (Собственно, GPS не для автомобильных навигаторов придумали: сеть спутников – это один из способов проверить другую навигационную информацию, хотя бы и при помощи специально оборудованного автомобиля.) Тем не менее, данные о рельефе – незаменимы. Особенно, под водой.

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

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

Воскресное чтение манускриптов. Манускрипт Vat.gr.1605 из Ватиканской Апостольской библиотеки уже несколько раз упоминался на dxdt.ru. Например, в связи с “кубосом”, иллюстрирующим способ вычисления объёмов. На соседней с “кубосом” странице этого манускрипта, а также на странице предыдушей, описаны и нарисованы круги, тоже с вычислениями. Их и рассмотрим.

Специалиста, подготовившего исходные тексты манускрипта, называют иногда Героном Византийским (не Александрийским, на которого он ссылается), иногда Героном Младшим, а также – византийским Анонимом. Манускрипт Vat.gr.1605 датируют одинадцатым веком, первая часть труда посвящена осадным машинам, методам взятия крепостей и прочим хитростям военного дела, а вторая часть называется “Геодезия” и посвящена сугубо практическим методам измерений “на местности”, которые необходимы, кроме прочего, “для правильного определения высоты крепостных стен, без приближения к ним”. Методы дистанционного измерения здесь, конечно, оптические и основаны на применении диоптры (διόπτρα) – угломерного прибора, предшественника теодолита. (Способы применения диоптры подробно разобраны у более известного Герона – Александрийского.) Именно при помощи диоптры предлагается измерять первый круг. Соответствующая схема круга – на скриншоте из манускрипта.

Буквой α обозначен центр круга, по периметру которого сидят кустики и лежат камни (и они тут не просто так нарисованы – см. ниже). Радиус круга – ρε под чертой (черта обозначает запись числа); это число 105, в греческих буквенных обозначениях: ρ == 100; ε == 5; Единица измерения длины: оргия (ὄργυια); то есть, буквально, сажень, однако это не важно для геометрической интерпретации. Слева, в вертикальной записи, обозначена длина окружности: χξ, что соответствует 600 + 60 == 660. Ближе к центру, снизу от α, – площадь круга: λδ καὶ χν, что означает 34 (λδ) [тысячи] и (лигатура ϗ) 600 + 50 == 650, всё вместе: 34650 (квадратных саженей). Тысячи на иллюстрации обозначены диагональной чертой перед λ, а в тексте – прямо записаны словом как “тысячи” (χιλιάδων), что хорошо видно на скриншоте (нижняя строка, я отметил зелёными линями и буквами).

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

В тексте манускрипта приводится и подробный расчёт параметров размеченного на земле круга, исходя из радиуса, который определяется при помощи измерения диоптрой. А именно: радиус нужно удвоить, получив диаметр: 105 * 2 == 210; так как длина окружности составляет “3⅐ диаметра”, то она равна 660, “поскольку это число содержит три раза по 210 и одну седьмую от 210”. Здесь отношение длины окружности к диаметру принято 3⅐, – приблизительно 3.14 в десятичной записи, – неплохое рациональное приближение современного π. Площадь круга находится из тех соображений, что произведение диаметра на длину окружности – это четыре площади круга, соответственно, нужно взять одну четверть от 210*660, что и даст 34650.

Заметьте, между прочим, что хоть это и 11 век, но одна четверть, как ни странно, тут уже сокращённо записывается с горизонтальной чертой, и очень похоже на 1/4 (см. в центр скриншота, отмечено зелёными цифрами и стрелкой).

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

Этот круг поменьше. Радиус: λε == 30 + 5 == 35 саженей; периметр: ςκ == 200 + 20 == 220 саженей; площадь круга: γων == 3 (тыс) + 800 + 50 == 3850 саженей – ровно в девять раз меньше предыдущего круга, что очередной раз подчёркивает полезные свойства рациональных чисел.

ML-KEM/Kyber – быстрая криптосистема. На типовой современной аппаратуре она быстрее и чем X25519, и чем ECDH, и чем RSA. К тому же – с заявленной постквантовой стойкостью. Почему подобную криптосистему не внедрили для Интернета раньше, и в качестве основной? Можно же предположить, что вместо RSA и классического протокола Диффи-Хеллмана разработали бы что-то сразу с постквантовой стойкостью?

Публикация алгоритма Шора тут, очевидно, играет важную роль. Но криптосистемы с постквантовой стойкостью предлагались и раньше, до публикации Шора. Да, современного понятия о “постквантовой стойкости” тогда не было, но неверно и считать, что алгоритм Шора взламывает всё, что было предложено раньше этого алгоритма. Например, криптосистема McEliece, в исходном варианте, предложена в 1978 году, за 16 лет до алгоритма Шора. Но алгоритм Шора не позволяет взломать McEliece, а постквантовая стойкость может идти в качестве автоматического бонуса. Однако современные варианты McEliece стали внедрять на практике недавно, уже после того, как “постквантовый шум” набрал обороты, и как раз по причине стойкости к алгоритму Шора. Так что, пусть постквантовая стойкость и возможна без алгоритма Шора, но само по себе это ничего не гарантирует в плане внедрения криптосистем.

Кстати, что касается алгоритмов ML-KEM/Kyber, то соответствующая сложная задача (LWE) была сформулирована в 2005 году, но исходные вычислительные проблемы на решётках (SVP и др.) – тоже изучались заметно раньше, с начала 80-х годов прошлого века.

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

Во-первых, в конце 70-х и начале 80-х годов прошлого века криптография, как ни крути, являлась даже более эзотерической областью, чем она есть сейчас. Тут, несомненно, важен вопрос регулирования и “криптовойн”. То есть, вот мы разбираем достаточно узкий вопрос: почему придумали, разработали и внедрили именно RSA с FFDH (классический вариант Диффи-Хеллмана, в конечном поле), а не что-то вроде McEliece/Kyber – но предположим, на минуточку, что регулирование в отношении “понижения стойкости” тут сыграло важную роль: в каких-то криптосистемах стойкость снижать проще, чем в других. Естественно, этот процесс напрямую связан с алгоритмическими особенностями криптосистем. В той же ML-KEM контролируемо снизить стойкость, оставаясь на уровне компьютерных систем начала 80-х годов прошлого века, несколько сложнее, чем реализовать то же самое для RSA, которая тут более “гладкая”. Речь, конечно, не идёт о планах грубо сломать криптосистему, выбрав нестойкие параметры – это не сложно сделать и для ML-KEM/Kyber. Под “контролируемым снижением” тут надо понимать такое снижение стойкости, которое выполняется из предположения, что реализация не обваливается совсем, становясь игрушечной. Конечно, это больше похоже на попытку выдать желаемое за действительное. Для процесса запрета стойкой криптографии сохранение стойкости просто не могло рассматриваться в качестве первостепенного критерия. Более того, та же исходная версия McEliece предоставляла лишь что-то около 64-битов стойкости. С другой стороны, как теперь понятно, странное и строгое регулирование внедрению конкретно RSA не помешало, но даже поспособствовало, выделив эту криптосистему при помощи административных и социальных рычагов. В момент резкого роста масштабов практического применения RSA, другие криптосистемы, ещё и не реализованные на практике, тут же оказались заведомо надолго заперты на периферии технологии, в области теоретической криптографии.

Во-вторых, использование “криптографических преобразований” для передачи данных в вычислительной сети 80-х годов не просто выглядело излишним, но и вызвало обоснованные опасения относительно неоптимального расхода драгоценной пропускной способности: тут каждый байт на счету, а предлагается нарастить данные ключами на много килобит. И когда RSA оказалась вне конкуренции, те же эллиптические криптосистемы довольно долго пробирались на уровень практики, опираясь именно на короткие, если сравнивать с RSA, ключи. Короткие ключи очень удобны. В криптосистемах типа ML-KEM – и, тем более, McElice, – ключи очень длинные. Даже если предположить, что вместо ECDSA/ECDH развивалось бы что-то подобное Kyber, то килобитные ключи однозначно бы закрыли путь к внедрению: потому что – какой смысл жертвовать так много байтов? Сейчас этот смысл полностью сводится к желаемой постквантовой стойкости.

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

Странная история.

Популярная тема – оценивать “успехи ИИ” в процентах “программного кода”, который эти ИИ-системы сгенерировали. Вот утверждают, что Anthropic ожидает “100% кода”, но через год. А в “Ведомостях” более “реалистичные” оценки: 25% кода (да и только в отдельно взятой финансовой структуре “Т-технологии”).

“Проценты сгенерированного программного кода” – очень занимательный показатель. И не так важно, в чём его взвешивать – в строках или килобайтах командных слов. Например, можно генерировать “тавтологические строки”, которые компилятор будет просто выкидывать: if(a == b){a = b}…; или for i in [0,100]: b = 10; и т.д. Какая доля таких строк может быть в тексте программы? Сколь угодно близкая к 100% – чтобы программа хоть что-то делала, конечно, придётся написать пару вызовов, условно, каких-нибудь print “Hello!”. Заметьте, что даже корректную реализацию всякого алгоритма на ЯВУ нетрудно растянуть по “строкам кода”, что уж говорить про некорректные реализации.

Получается, что программный код должен быть “оптимальным”, в каком-то смысле – только тогда его можно учитывать в качестве показателя. А оптимизация, как процесс, строго связана с алгоритмом. А алгоритм не понятен даже компилятору, что уж там ожидать от перебора внутри LLM. Возникают, как говорится, “некоторые трудности”.

Скажем, если пытаться считать в строках, то нужно учитывать, что разным бывает не только программный код (выбранный язык, способ записи), но и сами строки, на которые этот код разбивается. Возможно, предполагается, что итоговый алгоритм, соответствующий записи в коде, будет исполнять вычислительная машина – то есть, аппаратура. Понятно, что записи машинных команд в памяти этой аппаратуры нельзя считать строками (там нет нужной семантической структуры, а если выражаться простыми ESC-последовательностями, то отсутствуют “\r\n” в нужной интерпретации). Конечно, можно посчитать строки в коде на ассемблере. Здесь генераторы кода могут создавать NOP-последовательности (то есть, вызовы “пустых” команд). Ну и пустые по результату наборы эффективных команд тоже нельзя сбрасывать со счёта – проблем с их генерированием тут меньше, чем в случае, когда на страже путей преобразования стоит компилятор.

Я не так давно писал про нашумевшую публикацию Situational Awareness, где количество строк программного кода тоже используется в качестве некой меры уровня “суперинтеллекта” (AGI и далее). Там ожидается, что “суперинтеллект” будет писать “триллионы строк кода”. А самое главное – человек не сможет этот код понять, “даже если ИИ потратит годы на объяснения”. И эти вот годы, впустую потраченные суперинтеллектом, имеют тут интересное применение: могут ведь заявить, – как сейчас нередко и происходит, – что эти пустые строки – они “вовсе не пустые, а это вы просто не понимаете, что там написано суперинтеллектом”.

Насколько человек, – специально обученный, – может в принципе не понимать программный код? Этими человеками созданы сами используемые языки. Хорошо. Есть методы обфускации, которые понимание записи затрудняют: я тут обычно привожу в пример известный в узких кругах конкурс IOCCC, предмет которого и состоит в изяществе обфускации (кстати, конкурс недавно возобновили). Заметьте, что тут даже не важно, что программы на конкурс подают люди, важно, что авторы программ могут объяснить, что именно программа делает, на случай, если вдруг конкурсная комиссия не смогла разобраться своими силами.

Конечно, скорее всего, именно трудности с выявлением алгоритма по записи этого алгоритма прямо приводят к постановке проблемы P≟NP. Тем не менее, люди смогли сформулировать понятие об алгоритмической неразрешимости, и найти алгоритмически неразрешимые проблемы, объяснив, со строгими доказательствами, почему эти проблемы алгоритмически неразрешимы. При этом исходные объяснения с доказательствами получены, так сказать, без “искусственных интеллектов”. К этой области напрямую и относится вопрос о том, как можно было бы реально взвешивать ИИ по “доле программного кода”, им сгенерированного. И максимально упрощенный ответ очень простой: никак.

В Германии нашли (англ.) римский навесной замочек с золотым корпусом. Размер замка всего лишь 11 на 12 миллиметров. Датируют четвёртым-пятым веком (“около 400 года”). На коллаже ниже – реконструкция (большая) и фотография найденного замка (внизу слева).

(Credit: LWL /S. Brentführer.)

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

(Credit: LWL/S. Brentführer.)
Это, очевидно, увеличенная модель запорного механизма. Цепочка должна скользить по желобу, который на картинке виден слева (ориентирован вертикально). Когда замок заперт, скольжению мешает ригель (засов), зацепляющий звено цепочки. Ригель подпёрт “собачкой”, которая закреплена на задней стенке (плоский светлый элемент).

(Credit: LWL/S. Brentführer.)
Ключ вставлен и повернут. Бородка прижала “собачку” к стенке, ригель сдвинут – цепочку можно вынуть.

Реконструкцию внутреннего механизма сделали по результатам томографии исходного замка.

Понятно, что смысл подобного устройства, да ещё и в золотом корпусе, скорее декоративный. Максимум, чем такой замок мог бы быть полезен, так это фиксированием факта силового взлома.

CAA-запись в DNS позволяет управлять тем, какие УЦ могут выпускать сертификаты для имён в соответствующей доменной зоне. Проще говоря, в DNS публикуется имя УЦ, которому разрешено выпускать сертификаты. Чьё имя не указано – тем выпускать нельзя. (Есть тонкости с Wildcard-именами и уведомлениями о попытках заказа сертификата.) Интересно, что отсутствие CAA-записи в зоне разрешает выпуск всем. А если в CAA для имён УЦ указать пустой список (“;”), то выпускать нельзя никому.

То есть, тут мы неожиданно, на практике, сталкиваемся с весьма важной особенностью из области теоретической математики вообще и математической логики в частности. Речь про логики и формальные системы разного уровня. Пустой ящик – имеет совсем другой смысл, чем отсутствие ящика. Отсутствие ящика – это отсутствие CAA-записи, которое отсутствие вовсе и не эквивалентно пустому значению CAA-записи. Ящик есть, но он пуст – это наличие CAA-записи, значение которой – пустое множество. В первом случае, пустое множество – это “количество” CAA-записей в зоне. Во втором случае – количество УЦ, имена которых указаны в CAA-записи. Пустое множество при этом одно и то же, но оно укладывается в разные, рекурсивные ящики. Так можно построить натуральные числа.

Конечно, в спецификации этот подход использован не с целью построения натуральных чисел, а всего лишь с целью сделать использование CAA мягким. Иначе без доступа к DNS вообще не получилось бы сертификаты заказывать у УЦ, которые следуют CAA-записям.

В продолжение недавней записки про числа в ML-KEM. Один из ключевых параметров ML-KEM, одинаковый для всех наборов, это число (модуль) 3329. Почему выбрано именно 3329? Был ли выбор “случайным” (а иногда используют проверяемые методы для выбора параметров) или это число подобрано специально?

Число 3329, обозначаемое q, в ML-KEM выбрано строго специально. И вот из каких соображений. Весь практический вычислительный смысл ML-KEM (Kyber) в преобразовании (NTT), позволяющем быстро производить арифметические операции с полиномами. Чтобы быстрые операции NTT стали возможны в ML-KEM, число q должно быть простым, а (q-1) должно делиться на 256. (Более “общо” – делиться должно на степень двойки.) 256 – это другой параметр ML-KEM, его значение продиктовано разрядностью операций (256 бит).

То есть, 3329 – простое, (3329 – 1)/256 == 13. Если эти требования не выполняются, быстрый NTT работать должным образом не будет, поскольку это не настолько универсальный алгоритм, умножать полиномы “в лоб” – очень медленно, и другие быстрые алгоритмы – тоже оказываются медленными по сравнению с NTT. Неподалёку от 3329 не так много чисел, обладающих описанными свойствами: 257, 769, 3329, 7681, 7937. При этом, нужно выбрать число поменьше (важна экономия каждого бита), но чтобы не слишком выросла вероятность получения неверного результата при работе криптосистемы. Для 257 и 769 вероятность ошибки заметно больше. Поэтому авторы алгоритма выбрали 3329.

Оценка корректности употребления слов английского языка less и fewer нередко вызывает споры даже среди грамотных носителей языка. Эти слова различаются тем, что одно, в сравнении, модифицирует объекты как “неисчисляемые” (“неперечислимые”, если хотите), а второе – как “исчисляемые” (“перечислимые”). Если задуматься о том, что происходит, то можно обнаружить особенность, достаточно тонкую, которая модифицирует воспринимаемый смысл, переставляя фокус его построения между словами, следующими за less/fewer. Эффект напоминает “морфологический переворот”, который я как-то упоминал. Уловить изменение непросто, нужны хорошие иллюстрации. Такая иллюстрация попалась мне в стилистическом руководстве издания The Guardian, где эффект less/fewer рельефно проиллюстрирован четырьмя предложениями – все эти предложения говорят о разном, попутно закрывая все четыре возможных относительных варианта:

For less bad things to happen, fewer bad people need to be involved.
For fewer bad things to happen, less bad people need to be involved.
For fewer bad things to happen, fewer bad people need to be involved.
For less bad things to happen, less bad people need to be involved.

Перевод, понятно, эффект уничтожает. Но можно дать объяснение, используя несколько испорченные обороты на русском. Посмотрим на первое предложение: “Чтобы случались менее плохие вещи, меньше плохих людей должно быть вовлечено”. Less – “уменьшает” (сравнительно) то, что “нельзя посчитать”, отсюда привязка к bad. Bad, – здесь, – нельзя сравнивать “в натуральных числах”, то есть, нельзя сказать, что что-то хуже на “две единицы измерения ухудшения”. Поэтому “менее плохие” (дословный перевод здесь использован как иллюстрация). Fewer – обозначает тоже “меньше в количестве”, но именно в том количестве, которое можно считать. Поэтому “меньше плохих людей”, а не “менее плохие” “люди”. Всем известны примеры “неисчисляемых” существительных – “вода”, “песок” и т.д., – а равно и примеры “исчисляемых”: “кирпичи”, “мячи” и т.д.

Второе предложение: “Чтобы меньше плохих вещей случалось, менее плохие люди должны быть вовлечены”. Тут сравнительная характеристика “less bad” применяется уже к “людям”. Думаю, два оставшихся предложения несложно самостоятельно “раскодировать” аналогичным способом, наблюдая, как переключается фокус интерпретации.