Введение

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.

NOTE: Библиотека функционально закончена. Нового API или какого-то развития больше не ожидается. Только исправление ошибок.

Цели и задачи

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

Иметь криптографическую библиотеку на чистой Java без зависимостей, чтобы использовать её в своих проектах.
Только ГОСТ-алгоритмы без лишнего кода связанного с западным стандартами;
Готовые методы: потоковое шифрование + имитозащита для шифрования файлов или сокетов.
Реализацию TLS 1.3 для построения безопасных сетевых сервисов с российской криптографией.
JSSE-провайдер для интеграции криптографии с инфраструктурой Java.
Готовые и привычные инструменты для разработчиков и devops-инженеров для быстрого развертывания криптографической инфраструктуры в экосистеме Java.
Доступную с открытым кодом и нашей лицензией библиотеку для разработчиков.

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

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

Установка

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

mvn install.

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

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

gpg –import KEYS gpg -v v0.3.2
Способ 2. Скачайте артефакты отсюда и установите нужные модули. Для модуля crypto-gost-core пример установки:

mvn install:install-file
-Dfile=crypto-gost-core-0.3.2.jar
-Dsources=crypto-gost-core-0.3.2-sources.jar
-Djavadoc=crypto-gost-core-0.3.2-javadoc.jar
-DgroupId=org.rssys
-DartifactId=crypto-gost-core
-Dversion=0.3.2
-Dpackaging=jar

Затем, добавьте зависимость в pom.xml вашего проекта нужные модули:

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

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

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

Проверить подпись можно так:

gpg --import KEYS
gpg --verify crypto-gost-core-0.3.2.jar.asc crypto-gost-core-0.3.2.jar

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

Бенчмарки

Методики бенчмарков и кросс-валидации

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

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

mvn test — запуск тестов.
mvn package — получение дистрибутива библиотеки.
mvn install — установка дистрибутива библиотеки в локальный .m2.

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

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

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

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

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

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

Очень медленное шифрование/расшифрование по ГОСТ “Кузнечик”.
Есть проблемы с безопасностью реализации электронной подписи, некоторые из которых могут носить критический характер (об этом далее);
Если мне нужны только ГОСТ-алгоритмы, то 95% остального кода c западной криптографией мне не нужно.
Нужен контроль изменений в новых версиях, как в плане безопасности, так и производительности.
Отсутствие современной реализации TLS 1.3 для ГОСТ.
Безопасность, даже для личных проектов, очень важна. Авторы развивают прежде всего западные алгоритмы и устраняют недостатки в них.

Классический алгоритм электронной подписи на эллиптических кривых (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.

Изначально, часть кода этой библиотеки основана на BouncyCastle 1.83. Но сейчас код полностью переработан: исправлены недочёты оригинала, арифметика эллиптических кривых приведена в сторону безопасности, число k выполнено детерминированным (не путать с константным) по RFC 6979 вместо SecureRandom, ускорены алгоритмы шифрования. Реализация приведена в полное соответствие стандартам ГОСТ и RFC. В данной реализации библиотеке упала скорость электронной подписи в угоду безопасности.

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

В таблице приведена сравнительная оценка безопасности электронной подписи между двумя библиотеками. Там где указано 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 11+	JDK 8+

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

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

Лицензия

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

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