ГОСТ-криптография для разработчиков: что реально происходит при интеграции

Когда говорят «нужно добавить поддержку ГОСТ» — чаще всего имеют в виду задачу на пару дней. На практике это оказывается несколько недель, разбросанных по нескольким командам, с неожиданными открытиями на каждом слое стека.

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

---

Про алгоритмы — коротко и с 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. тот же KEK3. Key Unwrap: проверяет имитовставку, расшифровывает CEK4. Расшифровывает данные на 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 уберут. Пока работает, но это надо держать в голове при планировании.

Практические последствия по дистрибутивам:

Сборка (Debian 12 / Ubuntu 24.04)

# CMake >= 3.18 обязателен для OpenSSL 3.xsudo apt install cmake libssl-dev gitgit clone https://github.com/gost-engine/engine gost-enginecd gost-enginegit submodule update --initmkdir build && cd buildcmake -DCMAKE_BUILD_TYPE=Release ..cmake --build . --config Releasesudo 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 = gostdynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/gost.sodefault_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.pdfopenssl dgst -md_gost12_256 -verify gost_public.pem \  -signature signature.bin document.pdf

Для Python — PyGOST:

from pygost.gost3412_2015 import GOST3412Grasshopperfrom pygost.gost34112012 import GOST34112012256h = 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 = gostdynamic_path = /opt/cprocsp/lib/amd64/cp_gost.sodefault_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.2Public 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 между офисами, внутреннего инструмента — можно без лицензии. Как только вы начинаете делать это для клиентов — устанавливать, настраивать, обслуживать, продавать встроенную защищённую систему — нужна лицензия.

Самый неочевидный момент — встраивание. Если вы пишете приложение, используете в нём КриптоПро 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 — раздел для разработчиков. Там есть примеры кода, которые документация не всегда показывает очевидно.

Эта статья выросла из практики: в Пассворке мы регулярно сталкиваемся с вопросами криптографии и хранения секретов при работе с корпоративными клиентами в российском правовом поле.