Открытый ключ Kyber768 (постквантовой криптосистемы) – это 1184 байта, то есть, 9472 бита. Это заметно больше, чем занимает практический 8-килобитный ключ RSA. Для взлома такого RSA-ключа на квантовом компьютере (весьма гипотетическом), требуется количество логических кубитов в разных регистрах не меньше 24576 == 8K * 3. Но это теоретический минимум для логических кубитов, без учёта квантовых схем и возможной физической реальности. Поскольку технологические принципы реализации алгоритма Шора пока что не известны, оценки того, сколько физических кубитов и квантовых элементов потребуется для подобной разрядности, затруднены и сильно различаются, но нетрудно получить оценку в миллион (и более). И этот миллион квантовых эллементов, к тому же, может не сработать.

Естественно, это не отменяет того, что Kyber768 тут выглядит лучше, если обладает классической стойкостью. Кроме того, RSA – устаревшая криптосистема, а для коротких, относительно RSA, ключей ECDSA (например) – и кубитов потребуется поменьше, при этом прямо “растягивать” ту же ECDSA на несколько килобит – так себе идея.



Комментировать »

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



Комментировать »

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

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

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



Комментарии (1) »

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

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



Комментировать »

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

Screenshot with TLS 1.3 Kyber768

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



Комментировать »

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

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

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

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

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

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



Комментировать »

Всегда ли требуется знать значение секретного ключа, чтобы провести ту или иную атаку на систему аутентификации с подменой стороны? Вовсе нет.

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

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



Комментировать »

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

S-boxes

Хорошо виден основной эффект: в результате замены, расстояние между байтами возрастающей последовательности увеличивается, а “статистика”, порождаемая алгоритмом (n+1), скрывается. Подобные таблицы замены относятся к основным элементам, используемым при построении современных шифров. Естественно, сама по себе таблица никакой стойкости не обеспечивает, но, например, решает важную задачу “быстрого” размывания последовательностей “близких” значений во входных данных. Значения для замены специально подбираются так, чтобы эффективно решать именно эту задачу. От таблиц замены зависит стойкость шифров, так что исследование их свойств имеет большое значение (в том числе, с точки зрения обнаружения возможных архитектурных бэкдоров), в частности, конкретно с таблицами “Кузнечика” связана целая серия работ, но это тема для другой записки. Возможно, я напишу подробное описание работы шифра “Кузнечик” для dxdt.ru. С цветными картинками. (“Магма”, второй шифр из соответствующих ГОСТ, – достаточно давно подробно описан.)



Комментировать »

Stencil and punch cardСокрытие “статистики” входного потока данных – основная характеристика, связанная со стойкостью шифра. Собственно, в обобщённом смысле, цель использования шифра состоит именно в том, что, после обратимого преобразования, всякая “статистика”, порождающая различительные характеристики для входных сообщений, оказалась вычислительно эквивалентна случайной. Именно так нужно представлять эффект действия современного шифра. Можно представить, что есть некая “коробочка”, которая получает на вход открытый текст (исходное сообщение), а выводит либо результат зашифрования (с некоторым секретным ключом, который, для простоты, каждый раз новый), либо случайную, равновероятную последовательность битов (подходящую по длине). Тогда, для стойкого шифра, внешний наблюдатель, передающий в “коробочку” открытый текст, не может с высокой вероятностью определить, что именно пришло в ответ – результат зашифрования или случайные биты (тут нужно учитывать повторные попытки, свойства ключей, делать оговорки про вычислительные возможности и т.д., но это всё детали).

Так, если взять в качестве примера привычную запись текста на естественном языке, то простой шифр алфавитной замены (“А” -> “Д”, “Б” -> “Э” и т.д.: буквы заменяются на буквы по перестановке того же алфавита, ключом является перестановка) не обладает только что описанным свойством: если попросить “коробочку” зашифровать слово “длинношеее”, то результат, очевидно, получится угадываемым (ну, конечно, в той степени, в какой вообще можно поверить в случайные биты).

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

Интересно, что внесение дополнительного слоя сохранения некоторых статистических характеристик является одной из теоретических областей создания алгоритмических закладок/бэкдоров в шифрах. Представьте блочный шифр. То есть, такой шифр, который на вход получает, предположим, строго 256 битов и 256-битный ключ, а выводит тоже строго 256 битов шифротекста. Многие современные шифры так работают. Если шифр идеальный, то вывод будет равновероятным, а для успешного поиска нужно будет перебирать, хотя бы, 2^255 вариантов.

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

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



Комментировать »

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

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

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

Криптография, а точнее – криптология, работает, к сожалению, в обе стороны. Так, на первый взгляд, может показаться, что обеспечение строгой конфиденциальности подразумевает невозможность проверки содержания трафика на соответствие политикам блокировок: как же промежуточный узел будет инспектировать зашифрованный трафик, если раскрытие этого трафика нарушит конфиденциальность?

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

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

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

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



Комментировать »