Курс «Квантовые вычисления». Глава 14. Миграция на практике и квантовые коммуникации

Данные ИИ Разработка Безопасность Инфраструктура Квантовые вычисления Курсы и книги

2026 г.

Курс «Квантовые вычисления». Глава 14. Миграция на практике и квантовые коммуникации

Цели главы. Завершить курс тем, ради чего он писался: практикой. Стандарты и регуляторные сроки, устройство гибридных схем, план миграции организации, особые случаи (прошивки, PKI), и — для полноты картины — квантовое распределение ключей: как оно работает (у нас давно готовы все детали) и почему оно не заменяет PQC. Финал — лабораторная работа с настоящим постквантовым TLS и заключение курса.

14.1. Стандарты, сроки, состояние внедрения

Нормативная рамка (детали алгоритмов — глава 13):

13 августа 2024 года NIST опубликовал FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) и FIPS 205 (SLH-DSA). Для схем с состоянием ранее вышел SP 800-208 (LMS и XMSS). В марте 2025 года HQC выбрали для подготовки второго стандарта KEM; сам FIPS ещё не опубликован.
NIST IR 8547 по состоянию на август 2026 года остаётся Initial Public Draft. Он предлагает после 2030 года пометить 112-битные классические схемы как deprecated, после 2035-го запретить их, а квантово-уязвимые схемы с большей классической стойкостью запретить после 2035 года. Это проект американского переходного плана, а не уже действующий всемирный запрет. Сроки других агентств различаются: британский NCSC ставит вехи 2028/2031/2035, австралийский ASD рекомендует завершить переход к концу 2030 года.
Внедрение опередило завершение протокольного стандарта. Chrome использует ML-KEM в TLS 1.3 и QUIC по умолчанию на настольных системах с 2024 года; Go включает X25519MLKEM768 по умолчанию с 1.24; OpenSSL 3.5 реализует три FIPS-алгоритма и ставит X25519MLKEM768 первым в списке групп TLS 1.3. После широкого развёртывания IETF в августе 2026 года опубликовал RFC 10024 с тремя ECDHE-MLKEM-группами; X25519MLKEM768 получил статус Recommended. Подписи, X.509 и WebPKI требуют отдельной стандартизации и координации, поэтому локальная поддержка ML-DSA в библиотеке ещё не означает публично доверенный ML-DSA-сертификат.

Прочтите дорожные карты глазами неравенства Моски: если полная миграция занимает 5–10 лет, подготовка крупной организации начинается задолго до предельной даты. Конкретный план всё равно строят по собственным срокам конфиденциальности, жизненному циклу устройств и требованиям регулятора, а не простым копированием одной зарубежной таблицы.

14.2. Гибридные схемы

Распространённая стратегия переходного периода — гибрид: исполнить классическую и постквантовую схемы и подать оба результата в специфицированный комбинатор. В X25519MLKEM768 клиентский key_share состоит из 1184-байтного ключа инкапсуляции ML-KEM-768 и 32-байтного X25519; сервер отвечает 1088-байтным шифртекстом и своим 32-байтным X25519. Общий ввод для расписания TLS образуется как K_ML-KEM ‖ K_X25519, а транскрипт рукопожатия аутентифицируется штатным TLS 1.3. Поэтому ClientHello вырастает примерно на 1184 байта относительно одного X25519, ServerHello — на 1088, суммарно обмен — примерно на 2,2 КБ.

Цель конструкции — сохранить секретность, пока стойка хотя бы одна компонента: CRQC ломает X25519, но не известной атакой ML-KEM; гипотетический крах решёток оставляет X25519. Это свойство относится к проанализированному комбинатору внутри протокола и не переносится автоматически на самодельное «склеивание». Ошибки обработки, downgrade или не связанная с транскриптом компонента могут разрушить лозунг «нужно сломать обе». Увеличенный ClientHello действительно выявлял несовместимые middleboxes и маршруты, поэтому совместимость и наблюдаемость — часть миграции, а не мелочь после криптографии.

14.3. План миграции организации

Практичная последовательность, согласующаяся с рекомендациями нескольких агентств:

Инвентаризация. Составить криптографическую опись: где, что, для какой цели и на какой срок используется — протоколы, библиотеки, версии, сертификаты, ключи, оборудование, встроенные системы и договоры с поставщиками. Представление такой описи часто называют CBOM (Cryptography Bill of Materials); формат и полнота зависят от инструмента. Трудность не в самой таблице, а в обнаружении неявных зависимостей и владельцев обновления.
Приоритизация. Каждой системе сопоставить срок конфиденциальности данных, срок проверяемости подписей, критичность, длительность замены и внешние зависимости. Каналы с долгоживущими секретами получают высокий приоритет из-за HNDL; прошивки, корни доверия и архивные подписи могут быть столь же срочными из-за долгого жизненного цикла. Универсального правила «все подписи строго вторыми» нет.
Пилоты и совместимость. Там, где зрелый профиль уже есть, обновить библиотеку и испытать гибридные группы, размеры сообщений, задержки, фолбэк и телеметрию. Для TLS это часто конфигурация; для SSH, VPN, MLS и проприетарных протоколов готовность стандартов и обеих сторон надо проверять отдельно. Лабораторная работа ниже — TLS-пилот, а не универсальный рецепт.
Подписи и PKI. Выпуск ML-DSA-сертификатов требует поддержки форматов, УЦ, HSM, клиентов, CT, OCSP/CRL и политик доверия. Профили гибридных и постквантовых сертификатов ещё развиваются. Короткоживущие классические листовые сертификаты полезны для автоматизации и быстрого развёртывания нового алгоритма, но сами по себе не спасают от будущей подделки сертификата, если доверенный ключ издателя остаётся квантово-уязвимым.
Криптогибкость как архитектурный принцип. Урок миграций MD5 → SHA-1 → SHA-2, растягивавшихся на десятилетия: алгоритм, зашитый в код, формат или договор намертво, переживает свою криптостойкость. Изоляция криптографии за интерфейсами, согласование алгоритмов в протоколах, запрет «магических констант» — чтобы следующая смена алгоритма (а она будет) стала конфигурацией, а не проектом.

Особые случаи. Во встраиваемых системах важны не только размеры открытого ключа и подписи, но и рабочая память, стек, время проверки, энергия, защищённое хранение состояния и формат обновления. LMS/XMSS имеют зрелый профиль для подписи кода, но требуют безошибочного управления состоянием и не обязательно компактнее ML-DSA по каждому показателю. Устройства со сроком службы 15–30 лет, выпускаемые без проверенного механизма обновления алгоритмов и корней доверия, создают заранее известный миграционный тупик; требования к криптогибкости, резерву ресурсов и процедуре обновления надо закреплять при закупке.

14.4. Квантовое распределение ключей

Наконец — «квантовая криптография» в собственном смысле, и у нас готовы все ингредиенты: неортогональные состояния не различить достоверно (упражнение 5 главы 2), измерение возмущает состояние (глава 2), клонирование запрещено (глава 3).

Идеальный BB84 (Беннет, Брассар, 1984). Алиса кодирует случайные биты в случайно выбранных базисах: вычислительном {|0⟩, |1⟩} или адамаровском {|+⟩, |−⟩}; Боб измеряет каждый сигнал в случайном базисе. По аутентифицированному открытому каналу они сверяют базисы, а позиции с совпадением образуют просеянную строку. При полном простом перехвате-и-пересылке Ева в половине случаев выбирает неверный базис и в половине этих случаев вызывает несовпадение — 25% ошибок среди просеянных битов.

Общее утверждение тоньше лозунга «любое подслушивание гарантированно заметят». Алиса и Боб раскрывают случайную выборку и оценивают параметры канала. Если ошибок слишком много, они прерывают протокол; если уровень допустим, исправляют расхождения и применяют усиление секретности, сокращая строку настолько, чтобы ограничить информацию Евы с заданной вероятностью отказа. Доказательство учитывает конечную статистику и модель устройств. Практические системы часто посылают ослабленные когерентные импульсы, а не идеальные одиночные фотоны, и используют decoy states против атак на многофотонные импульсы.

Так почему же ответом отрасли на квантовую угрозу стала PQC, а не QKD? Инженерные ограничения принципиальны:

Инфраструктура: нужен специальный оптический канал и оборудование; достижимая скорость резко падает с потерями и расстоянием. Полноценные квантовые повторители остаются исследовательской задачей, а доверенные промежуточные узлы знают ключ и снимают сквозную гарантию; спутниковые каналы требуют отдельной дорогой инфраструктуры.
Аутентификация: BB84 требует аутентифицированного классического канала, иначе возможен человек посередине. Начальную аутентификацию дают заранее распределённый секрет или цифровая подпись; затем часть QKD-ключа можно тратить на информационно-стойкую аутентификацию. QKD не заменяет весь криптографический стек.
Реализация: доказательство относится к идеальным устройствам; реальные лазеры и детекторы дали целый жанр атак на реализацию (ослепление детекторов и т.п.).
Область применения: NSA считает PQC более дешёвым и сопровождаемым решением для своих систем; совместная позиция ANSSI, BSI, нидерландского и шведского агентств также отдаёт приоритет PQC и оставляет QKD нишевые случаи. Формулировки и программы исследований у агентств различаются, поэтому говорить об абсолютно единодушной мировой политике не следует.

Корректная итоговая рамка: PQC и QKD — не конкуренты, а разножанровые инструменты; для интернета, приложений и документов ответ — PQC, физика же одиночных фотонов пока остаётся специальной инфраструктурой. Для полноты упомянем E91 — вариант QKD на запутанных парах и неравенстве Белла (глава 3): подслушивание разрушает корреляции CHSH — красивое замыкание на материал части I.

14.5. Заключение курса

Оглянемся на пройденный путь. Мы начали с линейной алгебры и одного постулата измерения (часть I), построили модель вычислений и прошли лестницу алгоритмов до Шора и Гровера, очертив границы возможного (часть II), спустились в железо и убедились, что коррекция ошибок превращает «в принципе» в «инженерный план» (часть III), и закончили тем, что из всего этого следует для каждого, кто отвечает за данные (часть IV). Главная симметрия курса, которую хочется оставить читателю: квантовая механика одной рукой создала угрозу (Шор), а другой — и ответ на неё дала вполне классическая математика (решётки, хеши), тогда как квантовый ответ (QKD) остался нишевым. Понимание, а не страх и не хайп, — вот что отличает специалиста в этой теме, и если курс этому послужил, он удался.

Что читать дальше. Систематический учебник — Нильсен и Чуанг (библия предмета); живое изложение теории сложности — Ааронсон, «Quantum Computing Since Democritus»; за практикой PQC следить по публикациям NIST и инженерным блогам крупных внедрений; за состоянием железа — по рецензируемым публикациям (не пресс-релизам — критерии отличия мы разобрали в главе 9).

Итоги главы

FIPS 203/204/205 приняты; HQC только выбран для будущего стандарта. NIST IR 8547 ещё проект, а национальные сроки различаются, хотя горизонт 2030–2035 встречается часто.
X25519MLKEM768 был широко развёрнут до стандартизации и с августа 2026 года описан в RFC 10024; его проанализированный комбинатор стремится сохранить защиту при стойкости любой компоненты, но самодельный гибрид такой гарантии не получает.
Миграция: инвентаризация → риск и сроки → совместимые пилоты → подписи/PKI → постоянная криптогибкость; точная очередь определяется данными, артефактами и зависимостями.
QKD позволяет по параметрам канала получить ключ с доказуемой границей утечки, но требует специального оборудования и внешней аутентификации; это нишевое дополнение, не замена PQC.

Упражнения

В BB84 Алиса отправила 1000 фотонов. Сколько в среднем позиций попадёт в сырой ключ? Ева перехватывает и пересылает каждый десятый фотон — какой процент ошибок увидят стороны на сверяемой выборке и по какой формуле?
Почему сверка базисов по открытому каналу не помогает Еве, а сверка битов выборки не раскрывает ключ? Что делают с битами, использованными для сверки?
Схема «доверенных узлов» магистрального QKD: ключ рождается посегментно и переупаковывается в каждом узле. Какая гарантия BB84 при этом теряется и чем такой узел отличается от обычного VPN-концентратора с точки зрения модели угроз?
Составьте CBOM для маленькой компании: сайт за CDN, самописный API-сервер (TLS-терминация на nginx), SSH-доступ, подписанные обновления настольного клиента, резервные копии в облаке, VPN для сотрудников. Расставьте приоритеты миграции по Моске, указав x для каждой позиции.
Пусть профиль гибридной подписи требует успешной проверки и ECDSA, и ML-DSA и связывает обе подписи с одним сообщением и контекстом. Сравните его с гибридным KEM: какое свойство защищается и когда возникает атака? Почему HNDL делает обмен ключами особенно срочным, но не даёт права автоматически отложить долгоживущие подписи?
Ваш поставщик СКУД предлагает контроллеры со сроком службы 20 лет, прошивка подписывается ECDSA, механизм смены алгоритма подписи отсутствует. Составьте (2–3 пункта) требования к закупке, следующие из этой главы.

Ответы и указания. 1: около 500 позиций (базисы совпадают в половине случаев); простой intercept-resend вносит ошибку с вероятностью 1/4 на перехваченную просеянную позицию, поэтому при доле 10% ожидается около 2,5 процентного пункта поверх аппаратного фона. 3: теряется сквозная гарантия «ключ не был известен третьей стороне»: доверенный узел знает его открытым текстом, как VPN-концентратор; квантовая защита остаётся лишь на отдельных сегментах. 5: KEM защищает записываемый сегодня шифртрафик, поэтому HNDL действует до CRQC. Классическую подпись нельзя ретроспективно превратить в расшифровку, но после CRQC можно создавать новые подделки, а старые прошивки, документы и доверенные ключи могут оставаться значимыми десятилетиями; срок перехода определяется жизнью артефакта, а не простым правилом «подписи могут ждать».

Лабораторная работа 6 (итоговая). Постквантовая миграция в миниатюре

Легенда. Вы — инженер, которому поручили пилотную постквантовую миграцию: оценить цену новых примитивов, собрать постквантовую PKI, перевести канал на гибрид, обследовать окружение и составить план. Результат работы — не «команды выполнились», а отчёт с числами: все задания завершаются измерением, которое в него заносится. Это последняя лабораторная курса, и она сознательно ближе к рабочему заданию, чем к упражнению.

Подготовка. Нужен поддерживаемый и обновлённый OpenSSL не ниже 3.5; ветка 3.5 — LTS, а наличие алгоритмов зависит также от сборки и загруженных providers. До работы проверьте не только номер версии:

openssl version
openssl list -kem-algorithms | grep ML-KEM-768
openssl list -signature-algorithms | grep -E 'ML-DSA-65|SLH-DSA-SHA2-128s'
openssl list -tls1_3 -tls-groups | grep X25519MLKEM768

Если хотя бы одна проверка пуста, используйте отдельную актуальную сборку, не заменяя системную библиотеку вслепую. Квантовое железо не требуется — PQC выполняется на обычном процессоре.

Часть A. Примитивы и их цена

Задание A1. Цикл ML-KEM вручную. Сгенерируйте пару и прогоните инкапсуляцию/декапсуляцию:

openssl genpkey -algorithm ML-KEM-768 -out kem.key
openssl pkey -in kem.key -pubout -out kem.pub
openssl pkeyutl -encap -inkey kem.pub -pubin \
        -secret secret_alice.bin -out ciphertext.bin
openssl pkeyutl -decap -inkey kem.key \
        -in ciphertext.bin -secret secret_bob.bin
cmp secret_alice.bin secret_bob.bin && echo "Общий секрет совпал"

В отчёт: размеры файлов и различие между размером математического объекта и контейнера. Ровно 1088 и 32 байта должны занимать шифртекст и общий секрет. Число 1184 относится к сырому ключу инкапсуляции; файл kem.pub — PEM-кодированный SubjectPublicKeyInfo с ASN.1-оболочкой и base64, поэтому ls -l kem.pub не обязан показать 1184. Просмотрите ключ командой openssl pkey -pubin -in kem.pub -text -noout.

Задание A2. Скорость. Измерьте отдельно генерацию ключа, инкапсуляцию/декапсуляцию, подписание и проверку. В OpenSSL 3.5 предусмотрены режимы обзора KEM и подписей:

openssl speed -seconds 3 -kem-algorithms ML-KEM-768
openssl speed -seconds 3 -signature-algorithms ML-DSA-65
openssl speed -seconds 3 ecdhx25519 ecdsap256

Если полный обзор слишком долог, измерьте нужную операцию циклом, предварительно сделав один пробный вызов без подавления ошибок:

time for i in $(seq 100); do
  openssl pkeyutl -encap -inkey kem.pub -pubin \
          -secret /dev/null -out /dev/null 2>/dev/null
done

В отчёт: таблица операций в секунду и описание процессора, версии, provider и числа потоков. Сравните ML-KEM-768 с X25519, ML-DSA-65 с ECDSA P-256, но не подменяйте три разные операции одним числом. Возможный результат — решёточная операция быстрее классической на этом процессоре; это измерение конкретной реализации, а не свойство стандарта. Размеры, память и совместимость оцениваются отдельно.

Часть B. Постквантовая PKI

Задание B1. Учебная цепочка на ML-DSA. Соберите трёхзвенную локальную PKI: корень — ML-DSA-87, промежуточный и серверный лист — ML-DSA-65. Это проверка форматов и библиотеки, а не публично доверенная WebPKI.

# корневой УЦ (самоподписанный)
openssl req -x509 -newkey ML-DSA-87 -keyout root.key -out root.crt \
        -days 3650 -nodes -subj "/CN=Lab Root CA" \
        -addext "basicConstraints=critical,CA:TRUE,pathlen:1" \
        -addext "keyUsage=critical,keyCertSign,cRLSign"
# промежуточный: запрос + подпись корнем
openssl req -newkey ML-DSA-65 -keyout ica.key -out ica.csr \
        -nodes -subj "/CN=Lab Intermediate CA" \
        -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
        -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl x509 -req -in ica.csr -CA root.crt -CAkey root.key \
        -CAcreateserial -days 1825 -out ica.crt -copy_extensions copy
# серверный сертификат
openssl req -newkey ML-DSA-65 -keyout srv.key -out srv.csr \
        -nodes -subj "/CN=localhost" \
        -addext "basicConstraints=critical,CA:FALSE" \
        -addext "keyUsage=critical,digitalSignature" \
        -addext "extendedKeyUsage=serverAuth" \
        -addext "subjectAltName=DNS:localhost"
openssl x509 -req -in srv.csr -CA ica.crt -CAkey ica.key \
        -CAcreateserial -days 90 -out srv.crt -copy_extensions copy
# проверка цепочки
openssl verify -purpose sslserver -verify_hostname localhost \
        -CAfile root.crt -untrusted ica.crt srv.crt

Задание B2. Взвешивание. Соберите для контроля такую же цепочку на ECDSA P-256 и сравните: размер каждого сертификата, суммарный вес цепочки srv+ica (то, что сервер шлёт каждому клиенту), размер подписи в сертификате (openssl x509 -in srv.crt -noout -text).

В отчёт: таблица размеров в одинаковом формате и вывод — во сколько раз тяжелеют отправляемые лист и промежуточный сертификат. Объясните вклад открытых ключей и подписей и сравните его с разовым ростом key_share. Это количественная причина инженерной сложности PKI, но не доказательство, что её всегда безопасно мигрировать позже.

Часть C. Канал

Задание C1. Гибридное рукопожатие под микроскопом. В первом терминале поднимите сервер и оставьте его на переднем плане; после опытов остановите Ctrl+C:

openssl s_server -cert srv.crt -key srv.key -cert_chain ica.crt \
        -port 4433 -www

Во втором терминале выполните два соединения и сохраните полный, а не обрезанный head журнал:

openssl s_client -connect localhost:4433 -servername localhost \
        -groups X25519MLKEM768 -CAfile root.crt \
        -verify_return_error -brief -msg </dev/null \
        >hybrid.log 2>&1
openssl s_client -connect localhost:4433 -servername localhost \
        -groups X25519 -CAfile root.crt \
        -verify_return_error -brief -msg </dev/null \
        >classic.log 2>&1

В отчёт: согласованная группа, статус проверки цепочки и длины ClientHello/ServerHello в обоих журналах. Ожидаемая прибавка — около 1184 байт в ClientHello и 1088 в ServerHello, с небольшими протокольными накладными расходами. Первый запуск сочетает гибридное установление ключа и постквантовую ML-DSA-аутентификацию в пределах этой учебной PKI; назовите именно эти два свойства, а не просто «полностью квантобезопасно».

Задание C2. Даунгрейд и совместимость. Смоделируйте несовпадение возможностей: сервер, знающий только классику (-groups X25519), против клиента, предпочитающего гибрид (-groups X25519MLKEM768:X25519). Изучите в -msg лог: произойдёт ли соединение, увидите ли HelloRetryRequest, какая группа согласуется. Затем ужесточите клиента до -groups X25519MLKEM768 без запасного варианта.

В отчёт: три исхода (гибрид с обеих сторон; классический сервер и клиент с фолбэком; строгий гибридный клиент против классического сервера), наличие HelloRetryRequest и согласованная группа. Фолбэк нужен для совместимости, но наблюдаемость обязательна: незаметный постоянный уход на X25519 не защищает от HNDL. Отдельно проверьте путь через прокси/middlebox и не называйте любой сбой доказательством его вины.

Задание C3*. Пилот реального сервиса. Если nginx действительно связан с OpenSSL не ниже 3.5, сначала проверьте согласованную по умолчанию группу: OpenSSL 3.5 уже ставит X25519MLKEM768 первой. Если конфигурация приложения переопределяет список, испытайте ssl_ecdh_curve X25519MLKEM768:X25519; в стенде, проверьте конфигурацию штатной командой nginx, выполните гибридное и классическое соединения и предусмотрите откат. Одна строка может включить группу, но устойчивость к HNDL подтверждают журнал согласования, отсутствие систематического фолбэка и проверка всего боевого пути.

Часть D. Разведка и план

Задание D1. Постквантовый интернет вокруг вас. Автоматизируйте опрос: по списку из 8–10 сайтов (крупные международные, локальные, ваш собственный) выполните

for h in www.google.com www.cloudflare.com ...; do
  echo "$h"
  openssl s_client -connect "$h:443" -servername "$h" \
          -groups X25519MLKEM768 -brief </dev/null 2>&1 \
          | grep -E "Negotiated TLS1.3 group|Peer Temp Key|Server Temp Key|CONNECTION ESTABLISHED|error"
done

В отчёт: таблица «гибрид согласован / рукопожатие не удалось / результат неясен» и дата измерения. Не помечайте любой сбой словом «классика»: причиной могут быть сеть, SNI, версия клиента или политика сервера. Для неудач повторите обычное соединение без -groups. Если браузер не показывает группу в интерфейсе, используйте сетевой журнал или захват трафика, а не догадку.

Задание D2. Mini-CBOM собственной машины. Выполните «шаг 1 плана» для своего сервера или рабочей станции: соберите криптографическую опись минимум из трёх источников — слушающие TLS-сервисы (ss -tlnp), сертификаты с алгоритмами и сроками (openssl x509 -noout -subject -enddate -text по найденным файлам), типы ключей SSH-хоста (for k in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $k; done).

В отчёт — итоговая таблица плана: для каждой позиции — используемый алгоритм, срок жизни защищаемых данных x (оцените), уязвимость (Шор/Гровер/нет — по таблице главы 12), очередь миграции по неравенству Моски и конкретное действие. Эта таблица — квинтэссенция всего курса: от алгоритма Шора до строки в вашем плане работ.

Задание D3*. Подпись прошивки. Консервативный путь для долгоживущих подписей: подпишите файл «прошивки» бесстатусной хеш-схемой и сравните с ML-DSA по размеру подписи и времени подписания:

openssl genpkey -algorithm SLH-DSA-SHA2-128s -out fw.key
openssl pkey -in fw.key -pubout -out fw.pub
openssl pkeyutl -sign -inkey fw.key -in firmware.bin -out fw.sig
openssl pkeyutl -verify -inkey fw.pub -pubin \
        -in firmware.bin -sigfile fw.sig

В отчёт: размер подписи (для этого набора ожидается 7856 байт), время подписи и проверки, сравнение с ML-DSA-65 и вывод о пригодности для конкретного устройства. Не превращайте наблюдение «подпись велика» в универсальный запрет SLH-DSA: редкая подпись прошивки и массовое TLS-рукопожатие имеют разные ограничения.

Литература к главе

NIST IR 8547, "Transition to Post-Quantum Cryptography Standards," Initial Public Draft, 2024. csrc.nist.gov/pubs/ir/8547/ipd
C. Bennett, G. Brassard, "Quantum cryptography: Public key distribution and coin tossing," Proc. IEEE ICCSSP, 1984.
IETF RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," 2026. rfc-editor.org/info/rfc10024
NCSC, "Timelines for migration to post-quantum cryptography," 2025. ncsc.gov.uk/guidance/pqc-migration-timelines
ANSSI, BSI, NLNCSA and Swedish NCSA, "Position Paper on Quantum Key Distribution," 2024. cyber.gouv.fr
OpenSSL 3.5 documentation: pkeyutl, speed and TLS groups.

Предыдущая глава || Содержание курса

Новости IT

404 Not Found

nginx/1.24.0 (Ubuntu)

Все новости →

Связь с редакцией