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

В октябре 2008 года, пятнадцать лет назад, на dxdt.ru, например, вышла записка про загадочную программу DARPA GANDALF – носимую систему поиска, идентификации и определения координат радиопередатчиков:

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

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

В сентябре 2023 года на dxdt.ru записки выходили часто, так что некоторые можно снова отдельно отметить:

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

Простой пример “про измерения” – о сложностях работы с погрешностями, которые не отражают в тематических статьях СМИ;

VPN и DNS-сервисы с ECS: утечка сведений об адресах – сервисы DNS-резолверов могут выносить наружу данные об исходном сетевом подключении клиента;

Технические подробности: постквантовая криптосистема X25519Kyber768 в TLS – описание некоторых деталей использования криптосистемы с постквантовой стойкостью, которую недавно внедрили в браузер Chrome;

Квантовые компьютеры и аксиома непрерывности – как себе представлять квантовый компьютер и как его (гипотетическая) работа связана со свойствами онтологической границы между макро- и микрообъектами.

Raspberry Pi 5, как пишут, выйдет на новом чипсете: BCM2712 с четырёхъядерным Cortex-A76 и новым видеопроцессором; максимальный объём ОЗУ – те же 8Gb, но это выглядит достаточным для Rasberry Pi. А вот по питанию обещают существенно большее пиковое потребление – 12W (против заявленных 8W у Pi 4).

Я постоянно использую несколько Raspberry Pi нескольких поколений, начиная с первого (до сих пор работает, как ни странно) – эти одноплатные компьютеры успешно играют (или играли) вот такие роли: сервер для SDR-приёмника (радио-USB-Ethernet); управляющий сервер для бэкапов; выделенный лог-процессор (собирает с разных машин логи и периодически строит графики/диаграммы, которые можно просматривать браузером); в качестве контроллера погодной станции; в качестве WiFi-точки доступа с записью трафика. Список неполный – штука очень удобная, поскольку позволяет аппаратно разделить выполнение задач по, так сказать, разным темам. На dxdt.ru, впрочем, Raspberry Pi упоминается не так часто, но упоминается – например, в заметке про вычисления на разной аппаратуре или про модули LoRa.

Кстати, в продолжение предыдущей заметки. В исходной работе (почему-то по оригинальной ссылке её больше нет, но, думаю, можно найти) в качестве примера используется модификация аппаратного генератора (датчика) случайных чисел, которая приводит к снижению эффективной энтропии до значений, доступных для быстрого прямого перебора. Что это означает и как может работать на практике, а не в качестве примера? Конечно, если бы речь шла о прямой замене на максимальное количество в 2^32 различных значений для 128-битной разрядности, то такой дефект элементарно обнаружился бы: он не только быстро проявится на статистике, но и будет выглядеть максимально подозрительно даже для самых простых методов – 2^32 16-байтных значений сейчас влезает в ОЗУ некоторых ноутбуков. Поэтому речь идёт о другой схеме. Практическая реализация должна работать в другом контексте: предполагается, что сторона, которой известно секретное значение, по нескольким результатам выдачи генератора (задающие элементы – их может быть даже два или три) за 2^32 (например) операций вычислит внутреннее состояние генератора и получит следующее значение, которое генератор выдал (ну или получит 116 битов из 128, а остальные – подберёт на следующем шаге). Во многих протоколах значение случайного числа, которое выдал генератор, передаётся в открытом виде, так что его можно прочитать тем или иным способом. А дальше уже, из-за свойств симметричных шифров и/или хеш-функций, можно найти точные ключи перебором. При этом в выдаче всегда остаётся некоторая добавленная энтропия, – предположим, аппаратная, – которая мешает вычислительно отличить выдачу генератора от качественной, если не известен ключ.

Десять лет назад на dxdt.ru, например, появилась заметка про занятную реализацию аппаратных закладок. Цитата:

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

“Яндекс” окончательно отключил бесплатную “почту для домена” – один из немногих полезных сервисов старого “Яндекса”. Я довольно долго использовал этот сервис для некоторых доменов. Формально, “Яндекс” не совсем всё отключил, однако теперь почтовые сообщения пользователям можно только принимать, но не отправлять (“режим чтения”). Реалии развития интернетов. Надо заметить, что это весьма старый бесплатный сервис, который в своё время был, без преувеличения, прорывным, и к которому, в старом “Яндексе”, ещё и прилагался ценный DNS-хостинг, оснащённый пусть и несколько минималистичным, но удобным редактором записей. Потом это всё переиначили, заменив с отдельными плясками на малопонятный новый интерфейс, как бы “ориентированный на бизнес”, но, тем не менее, как-то там продолжало работать. А теперь даже и основной “Яндекс”, как веб-сервис, называется иначе, так что не удивительно – почту отключили окончательно: предлагается переходить на платный тариф с какими-то не совсем понятными, но явно недешёвыми, уровнями оплаты “за пользователя” (да ещё и дополнительные данные передавать). Конечно, смысла в таком переходе нет: если вдруг кто столкнулся, то я бы рекомендовал просто перенести почту к тому или иному хостеру; часто услугу хостинга электронной почты предоставляет регистратор домена (иногда – даже за сумму продления регистрации).

(Надо заметить, что Google, в сходном “порыве монетизации”, старые аккаунты GoogleApps, которые идут ещё с какой-то там “закрытой бета-версии”, всё же пока оставил бесплатными – по крайней мере, в моём случае. Не ясно, конечно, останется ли оно так и дальше.)

Надо заметить, что на экспериментальном сервере TLS подключений с постквантовой криптосистемой Kyber768 – пока что единицы, очень мало. Что, в общем-то, понятно: в различных распространённых утилитах эта криптосистема ещё не поддерживается (как минимум, нужно пересобирать с самой современной версией библиотек типа BoringSSL, потому что в OpenSSL пока что поддержки нет), и даже в браузере Chrome нужно отдельно переключать флаг, чтобы X25519Kyber768 заработала. Посмотрим, что будет, когда (и если) в Chrome поддержка станет доступной по умолчанию.

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

Переделал вывод открытого ключа Kyber768 на экспериментальном TLS-сервере – см. скриншот ниже. Открытый ключ Kyber768 состоит из трёх полиномов (256 коэффициентов, которые превращаются в 384 байта для каждого полинома) и дополнительного параметра в 32 байта (в выдаче сервера он называется Rho). То есть, ключ существенно отличается по представлению, например, от RSA, где открытый ключ можно представить как пару натуральных чисел, одно из которых большое (модуль), или от ECDSA, где открытый ключ – точка на кривой, а поэтому его можно представить как пару натуральных чисел, а если в “сжатом” виде, то как одно. Здесь речь о том, как максимально близко к математическим свойствам вывести значения ключей, так-то понятно, что в этой области всё можно отобразить в виде натурального числа (или в виде полинома, кому как нравится). В принципе, полиномы Kyber768 можно было бы распаковать и отобразить так, чтобы они и выглядели как полиномы, но тогда получится совсем уж мешанина на странице.

Продолжаем небольшую серию записок про TLS-сервер на tls13.1d.pw. Этот сервер передаёт несколько сертификатов, в том числе и один необычный сертификат, увидеть который можно только в выдаче той или иной специальной утилиты (например, s_client из OpenSSL) или упомянутым сервисом SSLLabs. Этот сертификат сервер генерирует (и даже подписывает, но это тут не важно) в самом начале установления соединения, а в поля Subject и Issuer записываются, соответственно, IP-адрес с номером порта клиента и имя выбранной криптосистемы обмена ключами. Это такой экзотический способ “посигналить” в (закрытой) части TLS-сообщений. Клиенты должны бы игнорировать неподходящий сертификат в процессе валидации (но могут и ошибку выдать, конечно).

Очень полезный тест SSLLabs для TLS пока что не умеет обнаруживать поддержку криптосистемы X25519Kyber768 сервером – см. фрагмент результатов для tls13.1d.pw на скриншоте ниже (Supported Named Groups). Это, собственно, понятно и логично: использование данной криптосистемы всё ещё находится в экспериментальном статусе, а поддержка на стороне сервера совсем не распространена.

(Кстати, в результатах указано, что имена групп/криптосистем выведены в порядке предпочтений сервера, но для tls13.1d.pw это не так – сейчас “предпочтение” есть только для X25519Kyber768, остальные криптосистемы выбираются по наличию клиентских key_share, перечню поддерживаемых групп, но при этом ещё и случайным образом отправляется HelloRetryRequest – именно из соображений, что иногда нужно отправить HelloRetryRequest, а не по составу полученных клиентских параметров; обычные TLS-серверы так вряд ли делают.)