Но самый любопытный и интригующий пассаж в отчете ASC X9 следующий. На момент публикации отчета самый большой квантовый компьютер имел 72 кубита. Однако, как указывают авторы отчета, есть мнение, что более мощные квантовые компьютеры существуют, но информация о них не опубликована. Авторы полагают, что могут существовать квантовые компьютеры примерно со 100 кубитами!
Заметь также, что речь идет не об одном квантовом компьютере, а о компьютерах во множественном числе, то есть их может быть как минимум два. Конспирология может косвенно подтверждаться данными, содержащимися в обзоре о потенциальном военном применении квантового компьютера. Но это открытые данные, и не самые последние. Не исключено, что есть еще и скрытая часть айсберга.
Неудивительно, что в 2016 году Национальный институт стандартов и технологий США (NIST) объявил конкурс постквантовых алгоритмов для стандартизации. Уже прошло два этапа конкурса, для участия в третьем этапе отобрано семь основных алгоритмов и восемь альтернативных.
Как ожидается, итоги третьего этапа будут подведены к середине 2022 года. Один‑два алгоритма для обмена ключами и для подписи могут стать стандартами для США. Не исключен и четвертый этап, где могут быть выбраны алгоритмы для применения в специальных областях. Пока же работа идет: проводятся семинары, представленные алгоритмы дорабатываются, разрабатываются и совершенствуются атаки на алгоритмы.
Постквантовый VPN
Одновременно с алгоритмами спешно разрабатывают и приложения, которые их реализуют. Развивается и поддерживается проект Open Quantum Safe (OQS). В его рамках создана библиотека liboqs, включающая ряд постквантовых алгоритмов (они приведены на схеме ниже). Библиотека интегрирована в OpenSSL и некоторые другие приложения.
В Microsoft запустили свой проект Post-quantum Cryptography и разрабатывают алгоритмы FrodoKEM, SIKE, Picnic и qTESLA, а также приложения Post-Quantum Crypto VPN, Post-Quantum TLS и Post-Quantum SSH.
Теперь каждый желающий может взять и установить у себя постквантовую OpenVPN. Пока, как предупреждают разработчики, только в экспериментальных целях и для тестирования, поскольку приложение еще не прошло строгого аудита и в нем могут быть ошибки. Да и сами алгоритмы официально не сертифицированы. Но на свой страх и риск — пожалуйста.
Самый простой путь установить постквантовую OpenVPN — это взять готовые файлы у Microsoft. Есть версии для Windows и для Linux.
В Linux архив можно распаковать прямо в корень файловой системы (на боевой системе так делать не стоит, но для виртуалки пойдет):
1 2 |
# mv pq-openvpn-linux-staged.tar.gz / # tar -xvf pq-openvpn-linux-staged.tar.gz |
Архив распакуется, разместив бинарник в /usr/local/openvpn и скрипт pq-openvpn.service в /etc/systemd/system.
Все настройки постквантовой OpenVPN аналогичны обычной OpenVPN, поэтому я не буду слишком распространяться. Разве что замечу, что в конфигурационном файле сервера и клиента обязательно необходимо задать директиву ecdh-curve, иначе обмен ключами будет классический, а не квантовый. Дефолт ecdh-curve p256_sikep434 (гибридный алгоритм первого уровня криптостойкости), но его все равно нужно указать.
На странице microsoft/PQCrypto-VPN на GitHub указано, что поддерживаются только алгоритмы Frodo и SIDH. Да, поддерживаются, но у меня клиент на Windows 10 c директивой в конфиге ecdh-curve frodo1344shake выдает ошибку чтения памяти. Это, конечно, может быть связано с конкретной конфигурацией моей операционной системы, драйверами или с особенностями материнской платы. А вот с алгоритмами frodo1344aes, frodo976shake, frodo640shake и другими этого семейства, включая гибридные алгоритмы, соединение происходит без замечаний. Экспериментируя, я попробовал разные алгоритмы для обмена ключами, в частности, работают явно не заявленные Microsoft гибридные алгоритмы p521_firesiber, p521_ntru_hps4096821 (соответственно, и чистые постквантовые, без классической кривой, тоже работают).
Не забывай, что постквантовые алгоритмы в этой реализации PQCrypto-VPN работают только для TLSv1.3, поэтому в конфигах сервера и клиента следует явно прописать tls-version-min 1.3.
Разработчик утверждает, что после соединения есть только один метод удостовериться, что обмен ключами состоялся с использованием постквантового алгоритма. На сервере в логе необходимо найти group_id:
1 |
Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, group_id 1278 (post-quantum key exchange) |
На скриншоте лога сервера эта строчка подчеркнута. Видно, что постквантовый алгоритм обмена ключами задействован, о чем свидетельствует строка post-quantum key exchange, иначе было бы NOT post-quantum key exchange. В данном случае group_id 1278 (NID OpenSSL) соотносится с обменом ключами, заданным в директиве конфига OpenVPN ecdh-curve p521_firesaber. То есть это гибридный алгоритм, состоящий из классического обмена ключами по протоколу Диффи — Хеллмана на эллиптической кривой P-521 и постквантового механизма инкапсуляции ключа FireSaber-KEM.
FireSaber-KEM соответствует пятому уровню криптостойкости и основан на трудности решения модульной задачи обучения с округлением (Module Learning with Rounding — MLWR), которая представляет собой вариант задачи обучения с ошибками (Learning With Erros — LWR). Она, в свою очередь, восходит к криптографии на решетках. Поговаривают, что в NIST криптографию на решетках любят больше всего.
Постквантовый OpenSSL
Пара слов об аутентификации на сервере при помощи сертификатов. Это могут быть как ключевые пары, основанные на классических криптографических алгоритмах, так и постквантовые схемы, а также гибридные. На странице проекта заявлены алгоритмы Picnic и qTESLA. Но можно задействовать и другие алгоритмы, включенные в постквантовый форк OpenSSL (QQS-OpenSSL).
Далее я расскажу, как установить QQS-OpenSSL на Debian 8.9.0.
Для начала понадобятся зависимости:
1 |
# apt install cmake gcc libtool libssl-dev make ninja-build git python3-pytest python3-pytest-xdist unzip xsltproc doxygen graphviz |
Далее клонируем код OQS-OpenSSL:
1 |
$ git clone --branch OQS-OpenSSL_1_1_1-stable https://github.com/open-quantum-safe/openssl.git OQS-OpenSSL |
Клонируем и устанавливаем библиотеку liboqs (указав каталог с QQS-OpenSSL в четвертой команде):
1 2 3 4 5 6 |
$ git clone --branch main https://github.com/open-quantum-safe/liboqs.git $ cd liboqs $ mkdir build && cd build $ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/путь/до/OQS-OpenSSL/oqs $ ninja # ninja install |
Переходим в каталог QQS-OpenSSL и запускаем сборку:
1 2 |
$ ./Configure no-shared linux-x86_64 -lm $ make |
Все. Дальше можно генерировать постквантовые ключи и выпускать сертификаты.
Если есть потребность применять алгоритмы подписи, не включенные по умолчанию, то до сборки OQS-OpenSSL в файле oqs-template/generate.yml необходимо для этого алгоритма заменить false на enable и затем выполнить две команды:
1 2 |
$ python3 oqs-template/generate.py $ make generate_crypto_objects |
Попробуем в качестве алгоритма подписи picnic_L1_UR. Во‑первых, потому, что после долгой зимы — пикник, во‑вторых, потому, что в этом алгоритме применено преобразование Унру, которое предполагается стойким в модели квантового случайного оракула.
Квантовый случайный оракул — схема, при которой противник может делать квантовые (в суперпозиции) запросы случайному оракулу. Это отличается от более распространенной классической конструкции Фиата — Шамира (Fiat — Shamir transform, FS), которая используется в алгоритмах picnic-L1-FS и аналогичных.
Что касается общей характеристики Picnic, то это алгоритм, основанный на криптографическом протоколе доказательства с нулевым разглашением (Zero-knowledge proof, ZKP). Протокол zk-SNARK того же семейства ZKP, что и Picnic, используется в криптовалюте Zcash, которую разработчики позиционируют как наиболее анонимную, не позволяющую узнать ни сумму транзакции, ни отправителя, ни получателя.
Итак, генерируем ключи по алгоритму picnicl1ur и выпускаем сертификаты. Для удобства в каталоге OQS-OpenSSL создадим подкаталог CERTFICATES и выполняем обычные для OpenSSL команды, изменив только алгоритм ключа:
1 2 3 |
$ apps/openssl genpkey -algorithm picnicl1ur -out CERTIFICATES/picnic_ca.key $ apps/openssl req -x509 -key CERTIFICATES/picnic_ca.key -out CERTIFICATES/picnic_ca.crt -subj "/CN=Picnic CA" -days 100 -sha512 -config apps/openssl.cnf |
Просматриваем сертификат:
1 |
$ apps/openssl x509 -noout -text -in CERTIFICATES/picnic_ca.crt |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
Certificate: Data: Version: 3 (0x2) Serial Number: 45:fd:ea:12:2c:a5:e5:d9:a6:97:46:57:bb:ad:a6:41:f2:d6:e9:ee Signature Algorithm: picnicl1ur Issuer: CN = Picnic CA Validity Not Before: Apr 12 05:48:21 2021 GMT Not After : Jul 21 05:48:21 2021 GMT Subject: CN = Picnic CA Subject Public Key Info: Public Key Algorithm: picnicl1ur picnicl1ur Public-Key: pub: 02:a3:97:fc:dd:2f:5d:83:3c:91:53:bb:af:b1:7f: 75:f1:21:1d:78:e3:f9:ca:fb:3a:61:a5:09:fe:22: d4:72:ac X509v3 extensions: X509v3 Subject Key Identifier: 82:AA:E9:CA:CB:63:4A:F4:78:AC:63:1F:F3:05:6D:64:B9:44:77:2E X509v3 Authority Key Identifier: keyid:82:AA:E9:CA:CB:63:4A:F4:78:AC:63:1F:F3:05:6D:64:B9:44:77:2E X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: picnicl1ur 21:82:09:59:16:85:a6:68:52:08:68:a6:02:99:aa:a9:90:14: |
Далее генерируем ключи и выпускаем сертификаты для сервера и клиентов. Для полезных расширений сертификата сначала создадим файл extensions примерно с таким содержимым:
1 2 3 4 5 6 7 8 9 10 11 |
[server] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth subjectAltName = @alt_names [alt_names] DNS = 192.168.3.5 [client] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth |
И выполняем команды для сервера:
1 2 |
$ apps/openssl req -new -newkey picnicl1ur -keyout CERTIFICATES/server.key -out CERTIFICATES/server.csr -nodes -subj "/CN=mysite.ru" -config apps/openssl.cnf -sha512 $ apps/openssl x509 -req -in CERTIFICATES/server.csr -out CERTIFICATES/server.crt -CA CERTIFICATES/picnic_ca.crt -days 50 -CAkey CERTIFICATES/picnic_ca.key -CAcreateserial -sha512 -extensions server -extfile extensions |
Для сертификата клиента аналогично, только пишем client вместо server.
Готовые файлы PQCrypto-VPN алгоритм picnicl1ur не поддерживает, поэтому придется собрать самому. Благо в Microsoft написали скрипт build.py, который все делает автоматически. Необходимые зависимости указаны в начале этого скрипта.
Заключение
После того как постквантовые алгоритмы будут стандартизированы, во всем мире начнется переход на постквантовую криптографию. Браузеры будут переведены на постквантовую криптографию (в Google уже проводили такой эксперимент в Chrome Canary). Переход будет долгий и трудоемкий, поэтому уже появились первые фирмы, предлагающие помощь во внедрении постквантовой криптографии, например PQShield при Оксфордском университете или российская QApp.