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

Кстати, в продолжение предыдущей заметки. В исходной работе (почему-то по оригинальной ссылке её больше нет, но, думаю, можно найти) в качестве примера используется модификация аппаратного генератора (датчика) случайных чисел, которая приводит к снижению эффективной энтропии до значений, доступных для быстрого прямого перебора. Что это означает и как может работать на практике, а не в качестве примера? Конечно, если бы речь шла о прямой замене на максимальное количество в 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-серверы так вряд ли делают.)

Всё же я пока восстановил свой экспериментальный сервер TLS 1.3 – tls13.1d.pw (некоторое время назад я писал, что собираюсь его совсем отключить). А чтобы восстановление выглядело поинтереснее, я реализовал на сервере поддержку постквантовой схемы получения общего секрета (KEM) X25519Kyber768. TLS с Kyber768 там реализован вручную, но я, впрочем, использовал криптопримитивы из удобной библиотеки Cloudflare.

Криптосистему с постквантовой схемой KEM Kyber768 в конце августа Google внедрил в браузер Chrome (в порядке эксперимента), так что можете проверить – на сервере у X25519Kyber768 повышен приоритет, поэтому, при наличии соответствующего открытого ключа в сообщении клиента, выбираться она должна довольно часто.

Вообще, открытый блок клиентского KeyShare в X25519Kyber768 весит аж 1216 байтов (32 + 1184, потому что это ключ X25519, 32 байта, плюс ключ постквантовой части Kyber768, который большой). Тем не менее, я всё же пока что сделал вывод этого ключа без сокращений, что, возможно, выглядит тяжеловато, но видно будет только в браузере с поддержкой данной криптосистемы. (Дополнение, 12/09/2023: технические подробности об использовании криптосистемы.)

Поддержка есть только в самых свежих версиях Chrome (>=116), а включать её нужно через флаги: chrome://flags, набрать “TLS13” в поиске, флаг называется “TLS 1.3 hybridized Kyber support”.

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

Записок в августе 2023 года вышло достаточно, чтобы некоторые отметить отдельно:

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

“Нормализация символов Unicode и доменные имена” – полезное описание одной весьма тонкой технической особенности применения Unicode в тех редких случаях, где применять Unicode не стоило бы;

“STARTTLS и SMTP” – как TLS “приспособительным” способом прицепляется к SMTP;

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

“Широкие проблемы применения ИИ” – из совсем свежих записок: интерпретация “перебора коэффициентов” в современной практике ИИ.

Вот так представляется бот, собирающий веб-страницы для разновидностей ChatGPT: “Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)”. В августе бот почему-то особенно активен на dxdt.ru, где, собственно, и был мной замечен в логах.