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

Как с максимальной точностью ответить на вопрос “Что ты сейчас читаешь?”, заданный в мессенджере? Можно ответить, что “читаю сообщение в мессенджере”. Но ведь можно же и ещё точнее: “Сейчас я читаю слово это”. И нажать Enter. Но и тут есть тонкость: слово “сейчас” стоит в самом начале, так что к моменту начала чтения слова “это” – “сейчас” уже устареет. Соответственно, максимально строгий вариант такой: “Я читаю последнее слово этого предложения сейчас”. Особенно продвинутые читатели спросят, почему же речь о слове, а не о последней букве, например. Очень просто: читать можно минимум слово, а отдельную букву читать нельзя (если, конечно, она не является словом). Этому есть много причин, основных две: во-первых, попробуйте прочитать “ъ” (твёрдый знак, а не сходная по начертанию газета или мнемонический знак, обозначающий некоторое сложное понятие); во-вторых, чтение, как процесс, определяется свойством сборки букв в слова (мы рассматриваем классическое фонетическое письмо, а не пиктограммы и специальные конструкции вроде трансцендентной алгебры). Так что разумно ограничиться словом “сейчас” в конце предложения. Без точки, это допустимо для чатика.

(Этот текст я как-то уже публиковал, но не здесь.)

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

Вот если в предложении “дерево весело задело” поменять “дерево” на “платье”, то изменится ли смысл? Сможет ли оценить изменение смысла человек, знакомый с русским языком?

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

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

Переделал вывод открытого ключа 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-серверы так вряд ли делают.)

Предполагается, что постквантовые криптосистемы – это защита от взлома на квантовом компьютере. На гипотетическом квантовом компьютере, который может реализовать соответствующие алгоритмы – алгоритм Шора, прежде всего. Конечно, современный уровень “хайпа” вокруг квантовых компьютеров уступает уровню “хайпа” вокруг “искусственного интеллекта”, тем не менее, квантовых компьютеров, подходящих для атак на используемые сейчас криптосистемы, ещё никто не показал. И даже ничего близко похожего – не показали. Но если почитать, например, статью про квантовые вычисления даже в англоязычной “Википедии”, то там почему-то уверенно обсуждаются “практические особенности”. Но до “практики” же ещё очень далеко. Пока что даже исследовательские алгоритмы, призванные показать “квантовое превосходство”, требуют создания специальных задач, которые структурно оптимизированы не в направлении вычислительной полезности, а в направлении использования свойств, потенциально доступных на имеющихся сейчас квантовых устройствах (см. boson sampling). Это естественно, весьма логично для этапа теоретических исследований на экспериментальном оборудовании, но не относится к практическому применению универсальных компьютеров.

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

Из этого, впрочем, не следует вывод, что квантовые компьютеры подходящей разрядности вообще не создадут. Но пока что трудности большие.

В продолжение недавней записки про X25519Kyber768 на TLS-сервере – подробности встраивания данной гибридной криптосистемы в схему работы TLS 1.3.

(Дополнение, 17/12/2024: в 2024 году Kyber768 была стандартизована NIST под обозначением ML-KEM; ML-KEM, как алгоритм, имеет некоторые отличия от Kyber768, поэтому две криптосистемы, хоть и совпадают по математической основе, но не совместимы на уровне операций. Браузеры, чтобы не поддерживать несколько максимально похожих криптосистем, использование которых сопряжено с передачей больших блоков данных, перешли с Kyber768 на ML-KEM, но тоже в составе “гибрида” X25519 + ML-KEM. Способ встраивания ML-KEM логически полностью совпадает с описанным ниже для Kyber768, отличается только порядок блоков данных.)

1. Как нетрудно догадаться, X25519Kyber768 состоит из X25519 и Kyber768, поэтому криптосистема и гибридная. X25519 – это хорошо известный вариант протокола Диффи-Хеллмана (DH), здесь используется без изменений, обычным образом (см. кстати, заметку с задачей про 2^255 – 19). Kyber768 – схема KEM (инкапсуляции ключа), построенная на криптосистеме Kyber с “постквантовой стойкостью”. Эта криптосистема реализует зашифрование с открытым ключом (важный момент).

2. В TLS рассматриваемая криптосистема используется для получения симметричного сеансового секрета. Открытый ключ передаётся клиентом в составе ClientHello, в расширении key_share, а ответная часть сервером – в ServerHello, key_share. В логике сообщений тут ничего не меняется.

3. Изменяется часть внутри key_share, соответствующая X25519Kyber768 – клиент передаёт результат конкатенации байтов, составляющих клиентскую часть DH X25519 и открытый ключ клиента Kyber768. Эти данные имеют фиксированную длину, определяемую алгоритмами: 32 начальных байта для X25519 и 1184 для Kyber768, 1216 байтов всего. На сервере данные разделяются (просто, по длине) и используются для обеих криптосистем. А именно: для X25519 сервер вычисляет общий секрет DH и серверную открытую часть DH (B), так же, как это делалось бы в случае отдельной криптосистемы X25519; для Kyber768 – сервер генерирует общий секрет и оборачивает его в KEM (то есть, зашифровывает исходное секретное значение, используя открытый ключ Kyber, присланный клиентом – тем самые 1184 байта). Два секрета сервер объединяет в один массив – здесь, опять же, простая конкатенация: BaseSecret = x25519[] + Kyber_Shared_Secret[]. Обратите внимание на важное техническое отличие: для X25519 общий секрет, на сервере, это результат умножения открытой части DH клиента (A) на секретный скаляр сервера d: s = d*A; а для Kyber – сервер выбирает исходное значение, которое отправляет клиенту в зашифрованном виде (очень похоже на устаревшую схему с RSA-шифрованием в TLS, но устроенную наоборот). При этом внутри KEM Kyber для вычисления секрета по исходному значению используется отдельная функция (KDF), подмешивающая ещё и значение открытого ключа, это необходимый шаг, но, с точки зрения логики получения секрета, это не так важно. Секрет, генерируемый в рамках Kyber768 в TLS – это тоже 32 байта (256 бит). После завершения данного этапа – сервер получил общий симметричный секрет, представляющий собой объединение выдачи двух алгоритмов: 32 байта и 32 байта. Также сервер получил открытую часть DH и зашифрованный Kyber симметричный секрет (это только часть, предназначенная для Kyber, результат X25519 сюда не попадает).

4. Сервер формирует ответное расширение key_share, присоединяя к 32 байтам открытой части DH X25519 байты шифротекста с симметричным секретом, который зашифрован Kyber – длина шифротекста 1088 байтов, всего 1120 байтов. Ответное key_share сервер отправляет клиенту в открытой части сообщений, в ServerHello, после чего генерирует на основе общего секрета набор симметричных сессионных ключей и переходит к зашифрованному обмену данными.

5. Клиент, получив key_share X25519Kyber768, разделяет данные на открытую часть обмена DH X25519 (B) и шифротекст Kyber768. По значению B DH клиент вычисляет общий секрет DH X25519 (здесь – 32 байта), который совпадает с серверным. Используя секретный ключ, клиент расшифровывает шифротекст и вычисляет общий секрет Kyber. Оба полученных значения объединяются, результат должен совпасть с серверным. (Тут слово “должен” использовано потому, что в Kyber, к сожалению, есть вероятностный элемент: так как это схема, концептуально происходящая из кодов с коррекцией ошибок, то имеется очень небольшая вероятность, что “ошибка” всё же останется, а клиент и сервер получат разные значения секрета.) На основе объединённого секрета клиент вычисляет набор симметричных ключей и может проверить подлинность и расшифровать следующие сообщения сервера.

Таким образом, Kyber простым и понятным способом добавляет 256 бит “постквантовой стойкости” к исходному симметричному секрету TLS-сессии, какие-то другие параметры – не изменяются.

Кстати, индекс 0x6399, который позволяет отличить ключи криптосистемы X25519Kyber768Draft00 в TLS-сообщениях, внесён в соответствующий реестр номеров IANA, в раздел под именем TLS Supported Groups. Название раздела – ещё один пример исторически сложившихся особенностей спецификаций: понятно, что X25519Kyber768 – никакая ни группа, а сразу две криптосистемы, построенные на различном математическом аппарате (но, естественно, группы нетрудно найти и в X25519, и в Kyber768). Изначально, упомянутый раздел параметров TLS содержал индексы именованных эллиптических кривых, то есть, сочетаний из параметров, определяющих конкретную кривую в прикладном смысле. Но так как для криптосистем существенны были именно операции в группе, а кроме эллиптических кривых ещё использовались (и используются) мультипликативные группы колец вычетов, то раздел, довольно давно, переименовали в “Поддерживаемые группы”, теперь туда записывают наборы криптосистем.

Развивающаяся “битва за банхаммер” приводит к тому, что в “этих интернетах” появляются новые плоскости для осуществления сегментации, поскольку блокирование сейчас модно делать на достаточно высоком уровне – на уровне приложений. Недавний пример – стена (временная) регистрации в Twitter. Есть масса других примеров, где администраторы вроде бы “глобального” массового сервиса ограничивают к нему доступ для некоторых IP-адресов, но не на уровне транспорта, а средствами HTTP или внутри приложения на смартфоне. Вообще, может показаться, что, с точки зрения “маршрутов” и BGP – ничего не меняется: пакеты если ходят, то так и ходят, как ходили. Для инженера NOC, допустим, прежде всего важно, что отправленный по заданному адресу пакет до этого адреса добрался, а что там происходит на уровнях, которые строятся из пакетов, HTTP это или QUIC какой-нибудь, – дело десятое.

Однако, хоть популярное нынче блокирование и выполняется на один или два уровня выше, чем IP, это самое блокирование может спуститься ниже, но уже в виде технологического спагетти. Это происходит в тот момент, когда просят как-то повзаимодействовать с этим блокированием (неважно, в какую сторону) на сетевом уровне. Всем знакомый пример: VPN-доступ, позволяющий прийти на сервис с другим (географически) сетевым адресом. IP заворачивается внутрь UDP, а туннели неожиданным образом проходят между логическими уровнями. А IP в туннеле используется для создания TLS-соединения со скрытым сервисом. Туннелирование туннелей. Сегментация на уровне приложений спускается в маршрутизацию, где порождает неожиданные эффекты доставки пакетов, особенно, если пересекается с anycast-узлами. Попробуйте зарисовать логику на листочке бумаги – получится путаница из спагетти, напоминающая нехорошую практику в области кабельных соединений.

Дело в том, что хоть блокировать многие предпочитают на разных уровнях, но привычный идентификатор, по которому ставят задачи блокирования, это всё равно IP-адрес (не всегда, но очень часто). Конечно, никто не отменял локального блокирования на уровне физических портов, на уровне приёма BGP-анонсов, однако для массовых и популярных сервисов, которые работают поверх Интернета, – это всё ещё применяется редко. Напротив, сейчас видно, как довольно быстро выстраивается новый перемешивающий уровень (хороший пример – технология ECH, создающая каналы “TLS внутри 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”.

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