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

Переделал вывод открытого ключа 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-сессии, какие-то другие параметры – не изменяются.

Всё же я пока восстановил свой экспериментальный сервер 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”.

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

Обычно, DNS-резолвер должен работать внутри VPN-сервиса – то есть, это может быть буквально обособленный резолвер, используемый именно в составе VPN (желательно, с DNSSEC). Но так делается далеко не всегда. Напомню, что DNS-резолвер (в данном случае, речь про рекурсивный резолвер) – это сервис, который проводит опрос серверов DNS, отыскивая, например, IP-адреса по именам узлов – адрес, по которому нужно браузеру обращаться к веб-серверу под именем test.ru. Резолвер выполняет то, что называется рекурсивным опросом: обращается к авторитативным DNS-серверам разных уровней. Эти серверы видят IP-адрес резолвера, но не клиента резолвера, который (вероятно) будет подключаться к сервису по обнаруженному в DNS адресу. При этом, для целей балансировки нагрузки на “целевой” сервис, DNS-серверу удобно было бы знать что-то о клиенте, для которого работает конкретный резолвер – потому что балансировка выполняется именно для клиента сервиса, а не для клиента DNS (сервис доменных имён (DNS) в этот момент уже на нужной стороне отработал). Это особенно актуально для больших открытых сервисов DNS-резолверов, например, Google Public DNS, так как эти сервисы обслуживают клиентов из самых разных точек сети. Чтобы как-то помочь оптимизации, довольно давно придумали расширение DNS под названием EDNS Client Subnet (ECS).

Данная технология (ECS) позволяет резолверу передать в сторону авторитативного сервера сведения об IP-подсети клиента, который обратился с запросом. Проще говоря – авторитативный сервер увидит IP-адресный блок, который соответствует клиенту, находящемуся за резолвером, что позволит определить провайдера. ECS как раз поддерживается Google Public DNS (и не только). Предполагается, что авторитативный сервер, определив провайдера клиента резолвера, сможет применить какие-то правила оптимизации. Если VPN используется для сокрытия IP-адреса пользовательского подключения, но DNS-трафик направляется не через VPN в какой-то DNS-сервис, то наличие ECS в этом сервисе (при прочих равных) означает, что внешние авторитативные DNS-серверы увидят скрываемую подсеть. Об этом нередко забывают.

Технический пример (не учитывающий NAT и другие тонкие настройки): предположим, клиентское устройство использует провайдерский доступ с адресом 10.11.12.13, ему соответствует подсеть 10.11.12.0/24; выход из VPN использует подключение с IP 10.22.22.22 (подсеть 10.22.22.0/24); DNS-трафик направляется напрямую (не через VPN) резолверу 10.53.53.53, резолвер поддерживает ECS. Тогда, при попытке определить значение A-записи (адрес), внешние серверы DNS узнают, что к ним подключается резолвер с адресом 10.53.53.53 для клиента из подсети 10.11.12.0/24. А вот на веб-сервере, к которому обращение произойдёт через VPN, адрес клиента будет виден как 10.22.22.22 – внешняя точка VPN. Естественно, если DNS-трафик маршрутизируется устройством через VPN, то внешний DNS-сервис с ECS сможет передать наружу только подсеть точки выхода VPN (10.22.22.0/24), поскольку именно адрес из этой подсети он видит в качестве источника запроса. Но лучше, конечно, если вообще используется собственный резолвер без ECS в составе VPN-сервиса, потому что возможны и другие каналы утечки метаинформации.

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

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

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

“Принцип Керкгоффса” (Kerckhoffs’s principle) в криптографии гласит, что планируемая стойкость криптосистемы не должна быть связана с тем, что сам используемый алгоритм держится в секрете (секретными должны быть только ключи). Но из этого вовсе не следует, что система с “секретным алгоритмом” заведомо нестойкая, как почему-то можно нередко прочитать – это как раз и есть обобщение, неверно основанное на более широком утверждении. Исходный практический принцип – о другом: если реализация криптосистемы оказалась в руках атакующего, то это не должно приводить к необходимости перехода на другую криптосистему, с другим алгоритмом, поскольку предыдущий оказался скомпрометирован.

Является ли криптосистема с “секретным алгоритмом” более стойкой или менее стойкой, по сравнению с “открытым алгоритмом”? С точки зрения оценки алгоритма, очевидно, сказать ничего нельзя: если “алгоритм секретный”, то его не оценить (но, конечно, “осадок остался”). Улучшается ли безопасность решения, использующего такой подход, в целом? Далеко не факт. Однако точно сказать довольно сложно – зависит от конкретной ситуации: нужно, как минимум, смотреть, в какой модели угроз действуют разработчики (действительно, может, они прежде всего защищаются от конкурирующей компании – кто первый выпустит очередную “умную лампочку”, а набор удачных алгоритмов позволяет экономить на аппаратуре).

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

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

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

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

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

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

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

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

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

Посмотрим, в качестве простого примера, на случай распознавания объектов на изображениях при помощи “обучения нейросетки”: тут на вход поступает большой набор параметров, который приводит к появлению на выходе согласованного с обучающей выборкой варианта из нескольких параметров, заранее заданных закрытым списком. Например, на входе – набор из сотен тысяч пикселей, снабжённых координатами, а на выходе – кортеж значений из названия объекта и некоторого числа: “лиса, 0.9”. Однако в какой-то момент об этом всём благополучно забывают и начинают считать, что данной нейросети что-то там стало известно о свойствах классифицируемых объектов, – например, о лисе, – и переформулируют результат: “на картинке лиса, с вероятностью 90%” (это сейчас происходит повсеместно, хотя именно о вероятности совпадения, да ещё и на выборке, отличной и от обучающей, и от тестовой, по показаниям такого фильтра – судить нельзя). Повышение значимости оценки же связано с тем, что такие манипуляции принято называть “искусственным интеллектом”. Но ведь используется всего лишь фильтр с неясными свойствами, полученный в результате псевдослучайного процесса, который гоняли на некоторой небольшой выборке входных значений. А вместо лисы на картинке может быть набор цветных треугольников, специально показанных в камеру (что неоднократно демонстрировалось на практике): “что мы знаем о лисе? ничего, и то не все”. Конечно, некоторые уже начинают о чём-то догадываться, рассказывают о “галлюцинирующих больших языковых моделях – LLM”, но, похоже, неприятных в своей массовости проблем всё равно не избежать.

В Chrome свежих версий добавлена экспериментальная поддержка “постквантового алгоритма” получения общего симметричного секрета для TLS 1.3 – X25519Kyber768. Это гибридный вариант, в котором в дополнение к “обычной” схеме X25519 используется криптосистема Kyber с заявленной высокой стойкостью ко взлому на гипотетическом универсальным квантовом компьютере (естественно, в дополнение к классической стойкости).

Технически это работает следующим образом: при установлении TLS-соединения Chrome добавляет в начальное сообщение ClientHello клиентскую часть данных X25519Kyber768 (и, естественно, индекс данной криптосистемы указывается в перечне поддерживаемых), если TLS-сервер может использовать данную криптосистему, то он выбирает соответствующий ключ из ClientHello, вычисляет симметричный секрет и использует его на дальнейших этапах. Это работает для TLS 1.3, при этом никак не изменяет каких-то других аспектов процесса установления соединения – не влияет на сертификаты и ключи к ним, не меняет шифров и т.д. На серверной стороне – обещают поддержку от Cloudflare и на некоторых узлах Google. Не вдаваясь в детали, можно смело считать, что X25519Kyber768 – это просто присоединение байтов секрета, полученного Kyber768, к байтам секрета, полученного X25519, на входе функции вычисления ключей для симметричного шифра, в полном соответствии с имеющейся схемой преобразования симметричных ключей TLS 1.3. То есть, схема, как минимум, не хуже криптосистемы X25519, которая уже давно используется, но не обладает постквантовой стойкостью (поскольку это вариант протокола Диффи-Хеллмана с логарифмированием в группе точек эллиптической кривой).

Насколько близки квантовые компьютеры, позволяющие быстро решать задачи отыскания соответствующих секретов асимметричных криптосистем, пока что не очень понятно. Однако постквантовые криптосистемы внедряются из предположения, что такой компьютер всё же может быть создан и позволит расшифровать ранее записанный трафик, из этого делается логичный вывод, что защиту нужно начинать внедрять заранее. Кстати, тут возникает не менее логичный вопрос: почему данный подход не применялся к разнотипным криптосистемам в том же TLS ранее, без требований о квантовых компьютерах? Например, можно же взять какую-нибудь экзотическую криптосистему и прикрепить её к распространённой реализации классического протокола Диффи-Хеллмана (DH), чтобы, если через двадцать лет будет найден неквантовый метод эффективного взлома классического DH, записанный трафик всё ещё оказался бы защищён (улучшения вычислительных атак на классический (“мультипликативный”) DH есть весьма существенные). Вопрос интересный, да. С одной стороны, задачи, на которых строятся распространённые сейчас асимметричные криптосистемы, нередко имеют математически эквивалентную структуру, с точки зрения сложности: то есть, одну задачу можно перевести в другую “с точностью до некоторой константы” (но тут есть куча оговорок – иногда “константа” получается слишком большой, например). С другой стороны, использование отдельного симметричного секрета, распределяемого по защищённому каналу, возможно и в TLS (называется PSK – Pre-Shared Key).