|
Professor Seleznov
|
Когда говорят «нужно добавить поддержку ГОСТ» — чаще всего имеют в виду задачу на пару дней. На практике это оказывается несколько недель, разбросанных по нескольким командам, с неожиданными открытиями на каждом слое стека. Попробую собрать в одном месте то, что обычно приходится выяснять по частям: какие алгоритмы актуальны, как выглядит их реальное применение в коде, где ломается интеграция и что со всем этим делает российское законодательство. - Про алгоритмы — коротко и с OID-ами OID (Object Identifier) — это числовой идентификатор вида 1.2.643.7.1.1.5.2, который криптобиблиотеки и сертификаты используют для обозначения алгоритма. Когда OpenSSL встречает в сертификате незнакомый OID — он не может его обработать. Именно поэтому без ГОСТ-движка openssl verify падает с unknown signature algorithm. OID-ы нужно знать, когда разбираешь совместимость или отлаживаешь парсинг. Актуальный ГОСТ-стек держится на четырёх стандартах. Всё остальное — либо легаси, либо режимы работы этих четырёх. ГОСТ Р 34.12-2015 содержит два блочных шифра. (Межгосударственный стандарт ГОСТ 34.12-2018 использует те же алгоритмы; в международных RFC — 7801 и 8891 — они опубликованы как ГОСТ Р 34.12-2015.) «Кузнечик» (RFC 7801, OID 1.2.643.7.1.1.5.2) — основной. 128-битный блок, 256-битный ключ, SP-сеть с 10 раундами. SP-сеть (Substitution-Permutation) — та же архитектура, что у AES: каждый раунд выполняет нелинейную замену байт и линейное перемешивание. Без аппаратного ускорения на массовых процессорах: AES-NI есть в каждом Intel/AMD с 2010 года, для «Кузнечика» ничего подобного нет — только в специализированных СКЗИ. «Магма» (RFC 8891, OID 1.2.643.7.1.1.5.1) — это ГОСТ 28147-89 с зафиксированными таблицами подстановок. 64-битный блок, 256-битный ключ, 32 раунда. 64-битный блок создаёт проблему birthday bound: когда вы шифруете примерно 2³² блоков одним ключом (это ~32 ГБ), вероятность столкновения двух блоков становится ощутимой. Злоумышленник, который наблюдает за зашифрованным трафиком, накапливает эту статистику и может начать восстанавливать информацию — это атака SWEET32. По этой причине «Магму» не используют для шифрования данных — её место в имитовставке (MAC — код аутентификации сообщений, проверяет что данные не подделаны) и Key Wrap (упаковка ключа — шифрование одного ключа другим ключом) внутри CMS, где объёмы небольшие. ГОСТ Р 34.11-2012 «Стрибог» (RFC 6986) — хеш-функция. OID для 256-битного варианта 1.2.643.7.1.1.2.2, для 512-битного 1.2.643.7.1.1.2.3. В 2018 году вошёл в ISO/IEC 10118-3, то есть является международно стандартизированным. Выпускается в двух вариантах: 256 бит — для большинства задач, 512 бит — для документов с длинным сроком хранения. ГОСТ Р 34.10-2012 (RFC 7091) — алгоритм электронной подписи на эллиптических кривых, используемый во всех российских криптографических профилях. OID для 256-битного варианта 1.2.643.7.1.1.1.1, для 512-битного 1.2.643.7.1.1.1.2. Относится к тому же классу алгоритмов, что и ECDSA, но отличается стандартом, параметрами кривых и кодированием — прямое приравнивание некорректно. Принципиальное отличие от RSA: в российской модели асимметрика не шифрует данные напрямую. Она используется для подписи и для выработки общего ключа по протоколу VKO (российский аналог Diffie-Hellman: обе стороны публично обмениваются частями, каждая вычисляет общий секрет самостоятельно, никто его не передаёт). Сами данные всегда шифруются симметрично — «Кузнечиком». Отдельного упоминания заслуживает режим CTR-ACPKM из ГОСТ Р 34.13-2015 (OID 1.2.643.7.1.1.4.2 для «Кузнечика», 1.2.643.7.1.1.4.3 для «Магмы»). Обычный режим CTR работает как генератор псевдослучайной последовательности: шифрует счётчик (0, 1, 2, ...) и накладывает на данные по XOR. Проблема: чем больше данных зашифровано одним ключом, тем больше статистики может собрать наблюдатель. ACPKM (Acyclic Pseudo-random Key Modification) периодически перегенерирует внутренние раундовые ключи прямо в процессе шифрования — без смены ключа в API и без видимых изменений для прикладного кода. Это российская инновация без прямого западного аналога. Конкретные лимиты данных на ключ и требование применять ACPKM задаёт конкретный профиль протокола: для PKCS#5/PBES2 — RFC 9337, для TLS — RFC 9189 (TLS 1.2) и RFC 9367 (TLS 1.3). Как выглядит ГОСТ-шифрование изнутри Типичная ошибка при первом знакомстве — думать о шифровании по RSA-модели: взяли открытый ключ получателя, зашифровали сообщение. В ГОСТ так не работает. Здесь используется гибридная схема: стороны договариваются об общем симметричном ключе по открытому каналу (как в ECDH — Diffie-Hellman на эллиптических кривых), а потом шифруют данные этим симметричным ключом. Но не прямо — сначала ГОСТ заворачивает симметричный ключ в отдельный «конверт». Вот что происходит при шифровании в формате ГОСТ CMS. CMS (Cryptographic Message Syntax) — это стандартный ASN.1-формат для зашифрованных и подписанных сообщений, аналог PGP-контейнера, только по стандарту RFC. Именно в CMS хранится то, что СКЗИ шлёт при шифровании файлов и почты:
Отправитель: 1. Генерирует эфемерную пару ключей (ec_ephemeral_priv, ec_ephemeral_pub) — «эфемерная» значит одноразовая: создаётся для одного сообщения и потом уничтожается. При условии, что реализация действительно уничтожает эфемерный ключ после использования, это даёт forward secrecy: если завтра утечёт основной ключ, вчерашние сообщения расшифровать не получится — эфемерного ключа уже нет нигде. 2. Генерирует случайный CEK (Content Encryption Key, 256 бит) — это симметричный ключ, которым будут шифроваться сами данные. 3. Генерирует UKM (User Keying Material, 8 байт) — случайная соль, которая делает каждое соединение уникальным даже при одинаковых ключах. 4. VKO: Z = VKO(ec_ephemeral_priv, recipient_pub_key, UKM) — VKO (Выработка Ключа Общего) — российский аналог ECDH. Обе стороны независимо вычисляют одну и ту же точку на эллиптической кривой, не передавая секрет по каналу. Результат Z — это общий секрет. 5. KDF: KEK = HKDF-Стрибог(Z, UKM, ...) — KDF (Key Derivation Function) превращает сырой общий секрет Z в ключ нужной длины и энтропии. KEK (Key Encryption Key) — ключ, которым будет зашифрован CEK. 6. Key Wrap: WrappedCEK = Магма-CBC-MAC(CEK) + Магма-ECB(CEK) на KEK — CEK шифруется на KEK алгоритмом «Магма» с добавлением имитовставки. Это и есть Key Wrap — упаковка ключа с защитой от подделки. 7. CipherText = Кузнечик-CTR(CEK, IV, plaintext) — сами данные шифруются «Кузнечиком». 8. Отправляет CMS EnvelopedData: {ec_ephemeral_pub, UKM, WrappedCEK, IV, CipherText} 9. ec_ephemeral_priv уничтожается навсегда. Получатель: 1. VKO: Z = VKO(recipient_priv_key, ec_ephemeral_pub, UKM) — та же точка 2. тот же KEK 3. Key Unwrap: проверяет имитовставку, расшифровывает CEK 4. Расшифровывает данные на CEK
Три момента, которые часто упускают. VKO — это не просто ECDH. В стандартном ECDH стороны просто перемножают ключи. В VKO дополнительно учитываются UKM и идентификатор алгоритма — это влияет на итоговый общий секрет. КриптоПро и ViPNet исторически интерпретировали некоторые детали по-разному, отсюда проблемы совместимости при межсистемном взаимодействии. Key Wrap через «Магму» обязателен по стандарту, даже если основные данные шифруются «Кузнечиком». Старый ГОСТ Key Wrap описан в RFC 4357; для сценариев с PBES2/PBKDF2 — RFC 9337. UKM должен быть настоящим случайным материалом из ГПСЧ СКЗИ (аппаратный или программный генератор псевдослучайных чисел, сертифицированный ФСБ). Если вы передадите в UKM детерминированное значение или просто нули — схема формально работает, но теряет часть защитных свойств. openssl-gost-engine: что работает, что нет Для разработки и несертифицированных сценариев подойдёт openssl-gost-engine. Но здесь есть важный контекст, который обычно упускают в инструкциях. ENGINE API умирает OpenSSL поддерживает два способа подключить сторонние алгоритмы. Старый — Engine API: динамически загружаемый .so-файл, который регистрирует свои реализации через устаревший внутренний интерфейс. Новый — Provider API: более изолированная архитектура, представленная в OpenSSL 3.0. OpenSSL 3.0 пометил Engine API как deprecated. gost-engine по-прежнему использует именно его — миграция на Provider API идёт (issue #496), но неспешно. В OpenSSL 4.0 ENGINE API уберут. Пока работает, но это надо держать в голове при планировании. Практические последствия по дистрибутивам:
| Дистрибутив |
Что делать |
| Astra Linux 1.8 |
Пакет libgost-astra, есть и engine, и provider |
| РЕД ОС |
openssl-gost-engine в дистрибутиве, включается через update-crypto-policies |
| Debian 12, Ubuntu 24.04 |
Пакета нет, сборка из исходников |
| Ubuntu 22.04 |
libengine-gost-openssl1.1 в репозитории, но не работает с системным OpenSSL 3 (разные ABI). Тоже сборка из исходников |
| Ubuntu 20.04 |
libengine-gost-openssl1.1 работает |
Сборка (Debian 12 / Ubuntu 24.04)
# CMake >= 3.18 обязателен для OpenSSL 3.x sudo apt install cmake libssl-dev git git clone https://github.com/gost-engine/engine gost-engine cd gost-engine git submodule update --init mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. cmake --build . --config Release sudo cmake --install .
Путь к .so непредсказуем — всегда проверяйте:
find /usr /lib /usr/local -name "gost.so" 2>/dev/null
openssl.cnf Добавьте в начало файла:
openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.so default_algorithms = ALL
CRYPT_PARAMS, который встречается в старых инструкциях — устаревший параметр для ГОСТ 28147-89, сейчас не нужен.
# Проверка что движок живой openssl engine -t gost # Актуальные имена cipher suites (они менялись между версиями движка) openssl ciphers | tr ':' '\n' | grep -i gost # GOST2012-KUZNYECHIK-KUZNYECHIKOMAC, GOST2012-MAGMA-MAGMAOMAC, ...
Ключи и подпись
# paramset:A — параметры эллиптической кривой (конкретная кривая из стандарта). # ГОСТ определяет несколько предопределённых наборов (A, B, C и ещё несколько), # paramset:A — стандартный выбор для большинства задач. openssl genpkey -algorithm gost2012_256 \ -pkeyopt paramset:A \ -out gost_private.pem # Самоподписанный сертификат для тестов openssl req -x509 -newkey gost2012_256 \ -pkeyopt paramset:A \ -nodes -keyout key.pem -out cert.pem \ -md_gost12_256 \ -subj "/C=RU/CN=test" # Подпись и проверка openssl dgst -md_gost12_256 -sign gost_private.pem \ -out signature.bin document.pdf openssl dgst -md_gost12_256 -verify gost_public.pem \ -signature signature.bin document.pdf
Для Python — PyGOST:
from pygost.gost3412_2015 import GOST3412Grasshopper from pygost.gost34112012 import GOST34112012256 h = GOST34112012256(b"hello, gost") print(h.hexdigest()) key = bytes(range(32)) cipher = GOST3412Grasshopper(key) encrypted = cipher.encrypt(bytes(16))
API менялся между версиями 6.x и 7.x, проверяйте документацию. КриптоПро и сертифицированный стек Когда нужна сертификация ФСБ — openssl-gost-engine не подходит, нужны коммерческие СКЗИ (средства криптографической защиты информации — так в российской регуляторике называются сертифицированные криптобиблиотеки и HSM-устройства). КриптоПро CSP 5.0 — де-факто стандарт. Под Windows работает через CryptoAPI, под Linux — через собственный демон cprocspd. Есть версии для Astra Linux, Альт, РЕД ОС. Конфиг OpenSSL для КриптоПро:
[openssl_init] engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost dynamic_path = /opt/cprocsp/lib/amd64/cp_gost.so default_algorithms = ALL
Ключи хранятся в /var/opt/cprocsp/keys/<username>/. Важно: ключевой контейнер — это директория из 6 файлов, а не один файл:
container_name.000/ ├── header.key ├── masks.key ├── masks2.key ├── name.key ├── primary.key └── primary2.key
Нельзя «скопировать ключ» одним файлом. При переносе копируется вся директория. ViPNet CSP — альтернатива от ИнфоТеКС. На уровне PKCS#11 и CryptoAPI совместим с КриптоПро, но детали VKO реализованы немного иначе. При межсистемном взаимодействии (КриптоПро на одной стороне, ViPNet на другой) проверяйте матрицу совместимости на tc26.ru перед выбором — там публикуются протоколы испытаний. Известен, например, случай, когда Континент TLS Client 2 не распознавал КриптоПро CSP 5 как провайдера. Где ломается
 nginx Исторически считалось, что ГОСТ TLS работает только с TLS 1.2 — и долгое время так и было. RFC 9189 определяет ГОСТ cipher suites для TLS 1.2. Но в 2022 году появился RFC 9367, который определяет ГОСТ cipher suites и механизмы согласования ключей уже для TLS 1.3. Фактическая поддержка TLS 1.3 с ГОСТ зависит от конкретного стека, версии СКЗИ и браузера — большинство существующих сертифицированных решений на 2026 год работают с TLS 1.2. Уточняйте у вашего поставщика СКЗИ. КриптоПро CSP 5.0 R2 поставляет патченный nginx (cpnginx). Конфиг:
ssl_certificate /etc/nginx/certs/server.crt; ssl_certificate_key /etc/nginx/certs/server.key; ssl_protocols TLSv1.2; ssl_ciphers GOST2012-KUZNYECHIK-KUZNYECHIKOMAC:GOST2012-MAGMA-MAGMAOMAC:LEGACY-GOST2012-GOST8912-GOST8912; ssl_prefer_server_ciphers on;
Проблема, про которую написано мелким шрифтом в документации КриптоПро: общий кеш TLS-сессий между воркерами не работает. Каждый воркер держит свой кеш, при балансировке между ними — полный handshake. ssl_session_cache shared:SSL:10m; не работает так, как вы ожидаете. Включайте ssl_session_tickets on; или выносите TLS-терминацию на выделенный шлюз (NGate, С-Терра, Континент TLS). Второй вариант — поставить ГОСТ-шлюз перед обычным nginx. Он терминирует ГОСТ TLS, дальше идёт обычный HTTPS. Заодно решает проблему с session cache и убирает из nginx зависимость от СКЗИ. Браузеры Chromium и Firefox ГОСТ не поддерживают. Для пользовательского доступа к ГОСТ-сайтам нужен Яндекс Браузер или Chromium-GOST — open-source форк, есть Linux-сборки. Часто путают две разные вещи: ГОСТ TLS (защита соединения) и подпись документов в браузере. Для второго нужно расширение КриптоПро ЭЦП Browser Plugin — это отдельный компонент, никак не связанный с TLS. Docker КриптоПро в контейнере требует конкретных флагов, без которых cprocspd просто не стартует:
docker run -d \ --privileged \ --security-opt seccomp=unconfined \ --tmpfs /run \ --tmpfs /run/lock \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ my-cryptopro-image
--tmpfs /run и --tmpfs /run/lock обязательны — без них cprocspd не может создать lock-файлы. Монтируйте ключи через volume:
volumes: - /var/opt/cprocsp/keys:/var/opt/cprocsp/keys:ro
Лицензия привязана к железу хоста, не к контейнеру. Пересоздание контейнера обычно не требует повторной активации, смена физического хоста — требует. Тестовая лицензия автоматически активируется на 3 месяца. Если сертификации не требуется — openssl-gost-engine в контейнере ставится без этих проблем. В репозитории gost-engine есть готовые Dockerfile для Debian и Alpine. Сертификаты ГОСТ-сертификаты формально X.509, но без ГОСТ-движка их не прочитать:
Signature Algorithm: GOST R 34.11-2012 with GOST R 34.10-2012 (256 bit) OID: 1.2.643.7.1.1.3.2 Public Key Algorithm: GOST R 34.10-2012 (256 bit) OID: 1.2.643.7.1.1.1.1 Parameters: GOST R 34.10-2012 256-bit ParamSet A OID: 1.2.643.7.1.2.1.1.1
openssl verify без движка выдаст unknown signature algorithm. Это ошибка среды, не сертификата. Классы СКЗИ ФСБ определяет классы КС1, КС2, КС3, КВ1, КВ2, КА1 — от минимальных требований до защиты от спецслужб с физическим доступом к оборудованию. Для большинства коммерческих задач актуальны первые три. КС1 — программная реализация без физической защиты. КриптоПро CSP в обычном режиме. Подходит для ИСПДн 3–4 уровня. КС2 требует контроля физического доступа к машине, где работает СКЗИ: журналы, режим помещения, список допущенных лиц. КС3 — аппаратный модуль доверенной загрузки, для КИИ второй категории и выше. Класс определяется в «модели угроз» — документе, который описывает кто и как может атаковать систему. Этот документ составляется при аттестации системы, и именно он диктует минимально необходимый класс СКЗИ. Повысить класс самостоятельно нельзя: если в модели угроз написано КС2, нужно физически выполнить требования КС2. Поставить ПО с сертификатом КС2 недостаточно. КЭП и форматы подписей Квалифицированная электронная подпись по 63-ФЗ — строго определённая конструкция: только ГОСТ Р 34.10-2012, только сертифицированное СКЗИ, сертификат только от аккредитованного УЦ. С 2022 года КЭП юрлиц выдаёт УЦ ФНС. Форматы подписей: CAdES (Advanced Electronic Signatures поверх CMS) — стандарт для большинства госсистем, СМЭВ, ФНС; XAdES — то же самое для XML-документов; PAdES — подпись встроена прямо в PDF-файл, не отдельным файлом. Реализовывать эти форматы самостоятельно не нужно. Есть готовые: КриптоПро PDF и Office Signature для документов, КриптоПро CAdES BES/Т для СМЭВ, DSS от КриптоПро для server-side подписи через REST. Постквантовый горизонт ГОСТ Р 34.10-2012 уязвим к алгоритму Шора, как и RSA с ECDSA. Квантовый компьютер нужного масштаба — не раньше 2030–2035 по оптимистичным оценкам. Но есть стратегия «harvest now, decrypt later»: противник уже сейчас записывает зашифрованный трафик, чтобы расшифровать его позже, когда появится нужный компьютер. Если ваши данные должны оставаться секретными через 15+ лет — думать об этом нужно уже сейчас. Симметрика в лучшем положении: алгоритм Гровера (квантовый поиск) снижает стойкость симметричных шифров вдвое по экспоненте — 256-битный ключ «Кузнечика» деградирует до ~128-битной стойкости, что по-прежнему считается безопасным. В российском контуре работает ТК 26, «Криптонит» опубликовал реализацию постквантового «Шиповника» (кодовая криптография). Стандарты ожидаются в 2026–2027 годах. Проектируйте крипто-слой с абстракцией над алгоритмом — захардкоженный VKO с конкретными параметрами кривой в пяти местах будет больно менять при миграции. Что ломается первым Несколько вещей, которые всплывают практически в каждом проекте. Поддержка ГОСТ затрагивает весь стек: хранение ключей, форматы сертификатов, TLS-профиль, форматы подписей, клиентские приложения, reverse proxy. Большинство систем мониторинга не понимают ГОСТ TLS и просто не видят соединения. Синтетические бенчмарки врут. Реальная производительность = TLS handshake + десериализация CMS + VKO + Key Unwrap + расшифровка. На benchmark вы измеряете только расшифровку. Забывают настроить жизненный цикл ключей. Сертификат КЭП действует год. У ключевых носителей тоже есть срок. Нужны процессы: кто инициирует, кто едет в УЦ, как обновляется в системе, что происходит в переходный период. openssl-gost-engine берут там, где нужна сертификация. Он технически корректен, но не является сертифицированным СКЗИ — это разные требования. Придумывают свою схему поверх стандарта. «Мы берём Кузнечик, но упаковку ключей сделали по-своему». Ломает безопасность (нестандартные схемы не проходили криптоанализ), совместимость и легитимность. Лицензии ФСБ и ФСТЭК: когда нужны разработчику Место, где технари чаще всего ошибаются — не потому что прячут голову в песок, а потому что граница действительно неочевидна. Основной документ — Постановление Правительства № 313 от 16.04.2012 (редакция 28.08.2023). В приложении — 28 видов лицензируемой деятельности: разработка СКЗИ, производство, распространение, монтаж и настройка на объектах клиентов, техническое обслуживание для третьих лиц, услуги в области шифрования. ПП № 313 прямо исключает из лицензирования техническое обслуживание СКЗИ для обеспечения собственных нужд юридического лица. Использовать КриптоПро для собственного ЭДО, VPN между офисами, внутреннего инструмента — можно без лицензии. Как только вы начинаете делать это для клиентов — устанавливать, настраивать, обслуживать, продавать встроенную защищённую систему — нужна лицензия.
| Ситуация |
Лицензия |
| КриптоПро для собственного ЭДО и VPN |
не нужна |
| Внутренний инструмент с ГОСТ-шифрованием |
не нужна |
| SaaS с TLS на уровне облака (не разрабатывает СКЗИ) |
не нужна |
| Продукт с встроенным СКЗИ — продаёте клиентам |
нужна |
| Устанавливаете и настраиваете СКЗИ у клиентов |
нужна |
| Обслуживаете СКЗИ у клиентов |
нужна |
| Аутсорс-бухгалтер подписывает отчёты клиентов своей КЭП |
нужна |
Самый неочевидный момент — встраивание. Если вы пишете приложение, используете в нём КриптоПро CSP через API и передаёте это приложение клиентам — вы разрабатываете и распространяете «защищённую с использованием шифровальных средств информационную систему» (п. 2 ПП № 313). Даже если СКЗИ клиент покупает напрямую у КриптоПро. ФСБ регулирует криптографию (шифрование, ЭП, ключи). ФСТЭК — техническую защиту информации без шифрования: межсетевые экраны, контроль доступа, DLP, аттестация. Две основные лицензии ФСТЭК: ТЗКИ — для услуг по аттестации и монтажу средств защиты; СЗКИ — для разработчиков СЗИ без криптографии. Если хотите получить сертификат ФСТЭК на свой продукт — нужна лицензия СЗКИ как заявитель. Требования к ТЗКИ/СЗКИ: 3+ сотрудника в штате с профильным образованием по ИБ, аттестованное помещение, аттестованные АРМ разработчиков, выездная проверка ФСТЭК. Ответственность Основная статья — ст. 13.13 КоАП («Незаконная деятельность в области защиты информации»): граждане 500–1 000 руб., должностные лица 4 000–5 000 руб., юрлица 30 000–40 000 руб., с возможной конфискацией средств защиты информации. Ч. 2 той же статьи (средства для защиты гостайны) предусматривает более строгие санкции. Суммы по ч. 1 выглядят небольшими, но конфискация СКЗИ и оборудования означает остановку деятельности. Ст. 14.1 КоАП применяется, когда деятельность квалифицируется как незаконное предпринимательство. Здесь важно разделить составы: ч. 2 (деятельность без лицензии) — штраф для юрлиц 40 000–50 000 руб.; ч. 3 (грубое нарушение лицензионных требований при наличии лицензии) — штраф до 200 000 руб. или административное приостановление деятельности до 90 суток. Приостановление — это именно ч. 3, а не автоматическое следствие отсутствия лицензии. Уголовная ответственность по ст. 171 УК наступает не автоматически, а при совокупности условий: предпринимательская деятельность без лицензии и либо причинение крупного ущерба (от 2 250 000 руб.), либо извлечение дохода в крупном размере (от 2 250 000 руб.). Ч. 1 — штраф до 300 000 руб. или арест до 6 месяцев. Ч. 2 (организованная группа или особо крупный размер — от 9 000 000 руб.) — до 5 лет лишения свободы. Ресурсы tc26.ru — официальные рекомендации по применению, параметры кривых, протоколы испытаний на совместимость между СКЗИ. Читать до начала проекта. RFC с тест-векторами и профилями: 7801 (Кузнечик), 8891 (Магма), 6986 (Стрибог), 7091 (подпись), 9215 (X.509 с ГОСТ), 4357 (Key Wrap и дополнительные алгоритмы), 9337 (PBES2/PBKDF2 с ГОСТ), 9189 (TLS 1.2 с ГОСТ), 9367 (TLS 1.3 с ГОСТ). github.com/gost-engine/engine — открытая реализация. Хороший источник тест-векторов для верификации своей реализации. cryptopro.ru/products/csp/docs — раздел для разработчиков. Там есть примеры кода, которые документация не всегда показывает очевидно. Эта статья выросла из практики: в Пассворке мы регулярно сталкиваемся с вопросами криптографии и хранения секретов при работе с корпоративными клиентами в российском правовом поле.-Источник
|