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

Предположим, что мы зашифровали некоторый небольшой текст (десяток слов) на естественном языке, используя самый обычный способ – кодирование UTF-8 и какой-нибудь стойкий симметричный шифр, например, AES с 256-битным ключом (32 байта). Но ключ выбран специальным способом: 30 байтов из 32 зафиксированы и известны, а два байта (то есть, 16 бит) выбираются случайно. Потом получившийся шифротекст отправляется в некоторую программу, программа перебирает значения двух “секретных” байтов ключа и пытается расшифровать данные, каждый раз проверяя, получились ли в результате словарные слова в кодировке UTF-8 (если хотите более “криптологический” вариант, то можно брать биграммы/триграммы – это как раз детали, которые здесь не важны). Если получились слова, похожие на ожидаемый язык, то программа считает, что удалось успешно расшифровать данные и выдаёт открытый текст.

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

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

В марте 2008 года, 15 лет назад, на dxdt.ru, например, появлялась записка про антенны с синтезированной апертурой для РЛС:

Можно сказать, что с математической стороны задача синтезирования сводится к определению характеристик некоторых электромагнитных полей по результатам измерений, сделанных в нескольких точках пространства в разное время. Задача местами сложная, но вполне разрешимая (особенно когда измеряется отражённое излучение от источника, характеристики которого соответствуют некоторым требованиям, – это как раз случай с РЛС).

В самом начале текста “Илиады” есть эпизод, в котором Аполлон обстреливает греческое войско, при этом в качестве первых целей, поражённых стрелами Аполлона (инфекцией, естественно), указаны вьючные животные и – собаки. В доступном исходном тексте про собак сказано, буквально, κύνας ἀργούς. “Собак” здесь – это κύνας (κύων), а вот их характеристику – ἀργούς – переводят по-разному, что выглядит довольно занимательно. Так, в русском переводе Н. И. Гнедича использовано весьма необычное слово “празднобродных” (“и псов празднобродных”), но в комментариях можно встретить, что вообще-то собаки “проворные”. Французский перевод (Leconte de Lisle) тоже обозначает собак как “проворных, быстрых” (rapide). В английских переводах характеристика собак в данном фрагменте либо вообще опускается (Pope), либо переводится тоже как “проворные” (“swift” – Buckley) и как “быстроногие” (“fleet” – Lang, Leaf, Myers).

При этом в комментариях к изданию перевода Бакли (Buckley) указано, что можно перевести и как “белые”. Действительно, в словаре – ἀργός, по первому значению, “белый, блистающий, яркий”; а второе значение – “быстрый, резвый, проворный” (словарь Дворецкого), но, опять же, с прямой отсылкой к собакам из эпического произведения Гомера. А есть и третье значение – бездеятельный, вялый, медленный, – однако указано, что этот вариант – от ἀεργία (“леность, безделье”); в этом варианте слово повсеместно используется у древнегреческих авторов, что, видимо, объясняет “празднобродных” собак.

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

“Аргоистые” собаки в “Илиаде” ещё встречаются. Например, в выражении “быстрые псы (κύνες ἀργοὶ) его прежде изгложут” (Гнедич). Почему глодать должны именно “быстрые псы” – из контекста (военные советы Полидамаса “шлемоблещущему Гектору” об обороне городов) не очень понятно. Впрочем, как и то, почему животные должны быть именно белыми (или “бледными”? тогда, хотя бы, можно предположить, что речь о слабых, больных псах).

(Заметка, конечно, никоим образом не претендует на статус “филологического комментария”, просто, данный момент с “бледными собаками” показался мне занятным.)

На одном из серверов, certbot, запускаемый по таймеру systemd, неожиданно сумел обновить сертификаты. Почему неожиданно? Потому что, как показало исследование логов, раньше этому certbot-у успешно мешал работающий там же веб-сервис: этот веб-сервис занимает 80/tcp, на который настроен и “респондер ACME/DCV” (проверка права управления доменом) в certbot; так что certbot, вообще-то, не мог штатным образом обновлять сертификаты (упомянутый веб-сервис имеет собственное подобие веб-сервера, которому не ведомо понятие web root, кроме прочего); попытка certbot-а поднять собственный веб-сервер, чтобы ответить на запрос из Let’s Encrypt, наталкивалась на занятость соответствующего интерфейса по нужному номеру порта. И поэтому сертификаты обновлялись совсем другим способом, хоть и через certbot. Но таймер-то продолжал работать. А тут на днях штатный веб-сервис отвалилися, 80/tcp стал доступен и – certbot успел самостоятельно перевыпустить сертификаты. Вот как бывает. Прописывайте, как говорится, параметры в конфигурационные файлы правильно, корректно настраивайте таймеры, это позволит избежать неожиданных проявлений деятельности “искусственного интеллекта”.

В Центре Сертификации (ЦС) ТЦИ планируется запуск API для внешней автоматизации (для организаций). Сейчас можно присоединиться к тестированию API:

ТЦИ разработал партнерское API для организаций, желающих осуществлять выпуск TLS- и S/MIME-сертификатов для веб-ресурсов и почтовых приложений.

Опубликовано на dxdt.ru 10 октября 2010 года – про теоретические особенности изготовления механических ключей по фотографии:

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

Кстати, о трафике на веб-узлах. Я поддерживаю тестовый сервер TLS 1.3 (https://tls13.1d.pw/) с HTTPS – это специальный сервер, написанный на языке Go и предназначенный, как нетрудно догадаться, для тестирования разных свойств TLS версиии 1.3. Cервер был запущен около пяти лет назад, когда спецификация TLS 1.3 ещё была черновиком. Надо заметить, что сейчас сервер принимает и обрабатывает примерно одно соединение в секунду (немало), часть из этих соединений – это TLS, а часть из TLS-соединений – это соединения версий 1.3 (“версий” – потому что иногда встречаются и draft-версии). Впрочем, по какой-то не совсем ясной причине, большинство успешных соединений инициируют клиенты, которые представляются как боты сервисов мониторинга доступности интернет-узлов. Представляются эти боты через строку User-Agent: сервер ориентирован на HTTPS, поэтому реализует минимальную логику обработки HTTP-заголовков, так что User-Agent – виден (но только для успешного TLS-соединения, понятно).

В конце 2018 года я добавил к тестовому серверу поддержку технологии ESNI, которая тогда находилась в состоянии эксперимента. Собственно, исходная версия ESNI поддерживается на tls13.1d.pw и сейчас, вот только поддержку ESNI удалили из браузеров и с серверов провайдера Cloudflare. Причина в том, что сама технология с тех пор была полностью переработана и теперь даже называется иначе – ECH. Так что, возможно, отключу поддержку ESNI. Тем более, что и ключи в DNS устарели. Конечно, надо бы взамен дописать реализацию ECH, но таких планов у меня нет, как и планов по развитию тестового сервера.

В заметке про практику 3D-печати я писал, что иногда использую Blender для того, чтобы реализовать “виртуальный предпросмотр” модели. Blender – это полнофункциональный и очень богатый по возможностям пакет для 3D-графики, собственно, один из немногих существующих. Естественно, применительно к 3D-печати – используется только малая часть возможностей. (Да, Blender применяют и в качестве инструментария для проектирования, но мне на этом направлении больше подходит OpenSCAD.) Вот, ниже, пример визуализации (Blender), использующий эффект прозрачности.

Это корпус для небольшого устройства на базе Arduino UNO (модель этого микроконтроллера видна внутри) с LCD, тремя кнопками на передней панели и местом установки динамика. Корпус состоит из двух частей, которые печатаются отдельно: основная коробка и лицевая панель – к ней крепятся блок кнопок и LCD (не показаны), а сама панель прикручивается шурупами к коробке.

Дополнение: версия “в стекле”, менее (а может – более) наглядная; распечатать такую, конечно, не выйдет.

Подписи DNSSEC в глобальном корне DNS появились в 2010 году. Это подписи криптосистемы RSA, которая сейчас считается устаревшей. Ввод DNSSEC прошёл в таком режиме, который не содержал даже механизма обновления корневых ключей – этот механизм внедрили существенно позже. Корневой ключ заменили, но криптосистема осталась той же – RSA. И вот, в 2023 году ICANN “планирует начать процесс подготовки” внедрения новых криптосистем в корневой зоне DNS: на днях опубликовали сообщение о создании рабочей группы. Можно предположить, что в корне DNS появится ECDSA, а может быть даже и что-то из разряда EdDSA (но этот вариант, конечно, вряд ли).

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

Разгадка cледующая. SSH-серверу просто не хватало локальной случайности – то есть, системного источника случайных чисел (/dev/random). Дело в том, что ядро (Linux) собирает энтропию для процесса, генерирующего (псевдо)случайные числа, так сказать, с доступной аппаратуры. В более или менее современных системах проблем с обильными источниками аппаратной энтропии нет, так или иначе, а вот если в очень старую систему на процессоре Intel поставить вместо шпиндельного винчестера SSD-накопитель, да отключить клавиатуру и видеокарту, то энтропии становится мало и её съедает само ядро при загрузке себя и сопутствующих модулей (напомню, что там есть всякие хитрые методы “рандомизации адресации”, направленные, как бы, на запутывание атакующих). Так как SSH-сервер использовал блокирующий вызов для получения случайных чисел (/dev/random вместо неблокирующего /dev/urandom), то ему приходилось ждать, пока накопится достаточно энтропии. SSH-серверу случайные числа нужны для криптографических операций, поэтому он и не мог принять входящее соединение. А вот если кто-то подключил клавиатуру, да ещё повозился в консоли, то энтропии становилось больше, хватало и для SSH. Чинится это либо установкой специального пакета типа haveged, который генерирует дополнительную энтропию программно (или программно-аппаратно, если хотите), либо добавлением аппаратного источника энтропии. Сейчас проблема менее актуальна: в дистрибутивы для платформ, где с получением энтропии трудности, haveged или подобное решение стали включать автоматически.

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

Ещё из области наблюдения над логами веб-сервера dxdt.ru: очень много записей со статусом 408 Request Timeout со стороны некоторых IP-адресов. Судя по всему, большинство из этих записей соответствует известной, в общем-то, ситуации: обычный клиент открывает TLS-сокет, но никаких HTTP-запросов не отправляет, поскольку сокет, например, был открыт заранее, на тот случай, если потребуется, однако – не потребовался; или просто соединение “зависло” где-то на промежуточных этапах доставки (скажем, не существует метода надёжно определить, что TCP-соединение фактически не завершено). В общем, раньше такое попадалось только на нагруженных веб-серверах, где большой трафик. Занятно, что большинство из таких “зависающих и пустых” сокетов от одного адреса связаны с мобильными устройствами (впрочем, предсказуемо).