red-stars-systems / crypto-gost
CI/CD
Реестр контейнеров и пакетов
mikeananev
Подготовка к релизу 0.5.4
6 часов назад История
README.md

Введение

crypto-gost — криптографическая библиотека алгоритмов ГОСТ на Java, а также сопутствующая обвязка вокруг них, позволяющая в полной мере внедрить ГОСТ в инфраструктуру Java.

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

Библиотека состоит из модулей:

  • crypto-gost-jsse - Реализация JSSE-провайдера для ГОСТ.

  • crypto-gost-netty - Netty SslContext-адаптер для ГОСТ.

  • crypto-gost-tls13 - Реализация протокола TLS 1.3 (RFC 8446) с поддержкой российских криптографических алгоритмов согласно RFC 9367.

  • crypto-gost-core - криптографическое ядро алгоритмов ГОСТ: Стрибог, Кузнечик, ГОСТ Р 34.10-2012, JCA-провайдер.

Целевая JDK при сборке модулей библиотеки: JDK 21.

Документация

Проекты на базе crypto-gost

Дальнейшее развитие cryptо-gost будет в этих проектах:

Цели и задачи

Создавая эту библиотеку я хотел устранить следующие недостатки:

  • Иметь криптографическую библиотеку на чистой Java без зависимостей, чтобы использовать её в своих проектах.

  • Только ГОСТ-алгоритмы без лишнего кода связанного с западным стандартами;

  • Готовые методы: потоковое шифрование + имитозащита для шифрования файлов или сокетов.

  • Реализацию TLS 1.3 для построения безопасных сетевых сервисов с российской криптографией.

  • JSSE-провайдер для интеграции криптографии с инфраструктурой Java.

  • Готовые и привычные инструменты для разработчиков и devops-инженеров для быстрого развертывания криптографической инфраструктуры в экосистеме Java.

  • Доступную с открытым кодом и нашей лицензией библиотеку для разработчиков.

Поддержать проект

Если проект оказался полезным, вы можете поддержать проект на Boosty

Установка

  • Способ 1 (рекомендуемый). Подключитесь к Maven-репозиторию GitFlic и добавьте зависимости в pom.xml вашего проекта.

Добавьте репозиторий:

<repositories>
    <repository>
        <id>gitflic</id>
        <url>https://registry.gitflic.ru/project/red-stars-systems/crypto-gost/package/-/maven</url>
    </repository>
</repositories>

Затем добавьте необходимые модули:

<dependency>
    <groupId>org.rssys</groupId>
    <artifactId>crypto-gost-core</artifactId>
    <version>0.5.4</version>
</dependency>

<dependency>
    <groupId>org.rssys</groupId>
    <artifactId>crypto-gost-tls13</artifactId>
    <version>0.5.4</version>
</dependency>

<dependency>
    <groupId>org.rssys</groupId>
    <artifactId>crypto-gost-jsse</artifactId>
    <version>0.5.4</version>
</dependency>

  • Способ 2. Клонируйте репозиторий и выполните сборку и установку в локальный .m2:

    mvn install.

    Все модули будут установлены в локальный .m2.

    При необходимости проверить подпись релизного тега можно так:

    gpg –import KEYS gpg -v v0.5.4

Методики кросс-валидации

Методики бенчмарков

Раздел для разработчиков

Для доработки библиотеки необходимо установить OpenJDK 21+, maven.

  • mvn test — запуск тестов.

  • mvn package — получение дистрибутива библиотеки.

  • mvn install — установка дистрибутива библиотеки в локальный .m2.

  • make doc — генерация md-файлов (Markdown) из adoc-файлов (asciidoc).

В папке bench созданы примеры кросс-верификации crypto-gost, BouncyCastle 1.83 и OpenSSL, а также много других бенчмарков.

В каталоге examples/ находятся интеграционные тесты и примеры использования.

Документация в этом проекте ведется в asciidoc-формате и на основе него генерируется в markdown и другие форматы.

Проблематика

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

Если вам нужна сильная криптография и гарантии её правильной работы - найдите профессионалов и доверьтесь им.

Разработчикам иногда требуется российская криптография для защиты данных. Для личных проектов или для целей локальной разработки в тестовой среде не всегда возможно использовать сертифицированные средства. Если у вас есть личный проект на нескольких серверах, то для установки в них российской криптографии и развертывания PKI-инфраструктуры придется сделать значительные усилия. Де-факто “стандартом” в области криптографии для Java для разработчиков стала библиотека Bouncycastle. Этой библиотеке много лет, есть обширная документация и книги, которые я считаю полезно изучить.

При использовании Bouncycastle имменно с российской криптографией я столкнулся со следующими трудностями:

  • Очень медленное шифрование/расшифрование по ГОСТ “Кузнечик”.

  • Есть проблемы с безопасностью реализации электронной подписи, некоторые из которых могут носить критический характер (об этом далее);

  • Если мне нужны только ГОСТ-алгоритмы, то 95% остального кода c западной криптографией мне не нужно.

  • Нужен контроль изменений в новых версиях, как в плане безопасности, так и производительности.

  • Отсутствие современной реализации TLS 1.3 для ГОСТ.

  • Безопасность, даже для личных проектов, очень важна. Авторы Bouncycastle развивают прежде всего западные алгоритмы и устраняют недостатки в них. В качестве примера развития ГОСТ по остаточному принципу приведу CVE-2025-14813 для режима шифрования CTR. Атакующий может восстановить открытый текст без знания ключа. Уязвимы все версии BC-JAVA от 1.59 до 1.83

Классический алгоритм электронной подписи на эллиптических кривых (ECDSA) при каждой подписи требует некое число k, которое нужно использовать при подписи совместно с закрытым ключом. Некоторые авторы реализуют ECDSA со случайным k, что требует криптографически качественного генератора случайных чисел (ГСЧ/RNG) при каждой подписи. А если ваш сайт или приложение работают в облачной среде, то неизвестно как настроена виртуализация и проброс энтропии в виртуальную машину для выработки случайных чисел k, нужных для каждой подписи.

Хочу отметить некоторые взломы на этой почве:

  • Sony PlayStation 3 (2010) — использовали константный k при подписи прошивок. Два уравнения с одним k → система из двух уравнений → закрытый ключ восстанавливается элементарно.

  • Android Bitcoin-кошельки (2013) — java.security.SecureRandom на Android имел дефект инициализации. Повторяющиеся k у разных пользователей привели к массовой краже биткоинов.

Отсюда можно сделать вывод, что если вы взяли Bouncycastle или любую другую библиотеку, то при подписи документов (ЭП) нужно иметь в виду, что:

  • повтор числа k → полная компроментация закрытого ключа подписи;

  • предсказуемый k → тоже компроментация закрытого ключа подписи;

  • слабый ГСЧ(RNG) в облаке или специфических условиях → катастрофа.

  • утечки ключа через атаки по таймингу (timing) или по сторонним каналам (side channels). Для криптографии нельзя выполнять умножение/деление больших чисел обычным способом, т.к. это создаёт риск утечки закрытого ключа при наличии доступа к времени выполнения операций. Особенно, если ваш сервис можно дергать по API. Нужна специальная математика и защитные техники, строгий контроль, чего рядовой разработчик просто не знает, отсюда и обоснование сертификации средств СКЗИ для серьезных проектов и корректности их встраивания.

SecureRandom в Java сегодня — криптографически надёжный. Основная угроза — не алгоритм, а окружение (энтропия в VM), которую использует BouncyCastle.

Код данной библиотеки разработан с учетом текущих требований по безопасности. Реализация приведена в полное соответствие стандартам ГОСТ и RFC. Арифметика эллиптических кривых приведена в сторону безопасности, число k выполнено детерминированным (не путать с константным) по RFC 6979 вместо SecureRandom, ускорены алгоритмы шифрования. Устранены все найденные утечки по сторонним каналам, намколько это возможно на чистой Java. В данной реализации библиотеке упала скорость электронной подписи в угоду безопасности.

Улучшения в безопасности электронной подписи в crypto-gost

В таблице приведена сравнительная оценка безопасности электронной подписи между двумя библиотеками. Там где указано constant time(CT) это положительное свойство. Злоумышленник может посылать разные данные и запросы. Если криптографические операции выполняются за одно и то же время, то такое свойство реализации не дает злоумышленнику никаких данных. Отсутствие constant time свойства у операций, это серьезный риск утечки закрытого ключа.

Сравнение реализации ГОСТ Р 34.10-2012 crypto-gost с BouncyCastle 1.83
Свойство crypto-gost
(текущая версия)		 BouncyCastle 1.83

Арифметика поля (ГОСТ-кривые)

Защищено
Montgomery CIOS, long[],
constant-time

BigInteger через ECFieldElement.Fp.modMult()

Координаты точки

Проективные Якоби,
только long[]

ECFieldElement.Fp на BigInteger, координатная система Якоби`.

Timing side-channel арифметики поля

Защищено
(constant time без ветвлений по данным)

Уязвимо
(переменное время BigInteger)

Скалярное умножение секретного k

Защищено
Montgomery ladder
(constant-time)

Уязвимо
wNAF / FixedPointCombMultiplier
(не constant time)

Timing side-channel скалярного умножения

Защищено

Уязвимо

Инверсия в поле при normalize()

z(p−2) mod p, CT ladder (теорема Ферма)

BigInteger.modInverse() (алгоритм Евклида, не constant time)

Timing side-channel инверсии z → k

Защищено

Уязвимо

Генерация эфемерного ключа k

Защищено
RFC 6979 (детерминированный HMAC-DRBG)

SecureRandom
(зависит от ГСЧ и окружения)

Устойчивость к атакам на RNG

Защищено
(k не зависит от ГСЧ/RNG)

Зависит от качества источника энтропии в окружении.

Интерпретация хэша (RFC 7091 §5.3)

LSB-first (reverseBytes), точно по стандарту ГОСТ

Требует отдельной проверки для каждой версии библиотеки

Зачистка ключевого материала

Выполняется
Destroyable
Arrays.fill(dBytes, 0)

Частично
(нет явного Destroyable для ГОСТ-ключей)

Условная редукция (constant-time)

constant-time-маска без ветвления в conditionalSubtract

Не применимо (BigInteger непрозрачен)

Вычисление маски бесконечности

(acc | -acc) >>> 63 (CT, без тернарного оператора)

Не применимо

Shamir’s trick при верификации подписи

shamirMultiply - интерливинговый wNAF,
z1·G + z2·Q за один проход

ECAlgorithms.implShamirsTrickWNaf,
аналогичный алгоритм

Совместимость JVM

JDK 21+

JDK 8+

Данная реализация crypto-gost претендует на более защищенный уровень по нескольким параметрам, который к тому же не зависит от качества ДСЧ (RNG) в облаке/окружении при подписи сообщений.
Данное утверждение требует подтверждения с помощью независимого аудита.

Нужно отметить существенное падение скорости подписи и проверки в crypto-gost, связанные с реализацией. Что лучше: безопасность vs скорость? Данная библиотека поставила целью преследовать безопасность, как наивысший критерий. Какой смысл в быстрой подписи, если любая операция ведет к компроментации закрытого ключа.

С учетом CVE-2025-14813 и вышеприведенной таблицы в части электронной подписи, я категорически не рекомендую использовать ГОСТ от Bouncycastle даже для личных проектов.

Лицензия

Автор: Михаил Ананьев.

Данный проект распространяется под Открытой лицензией на программное обеспечение “Рэд старс системс”, версия 1.0.
Текст лицензии находится в файле LICENSE или по ссылке.

Описание
Реализация криптографических алгоритмов ГОСТ на Java
Readme
0 Форки
11 Звезд
2 Наблюдатели
Посмотреть файловое дерево
Конвейеры
0 успешных
0 с ошибкой
Разработчики