При тестировании JCP/JTLS (rel 1.0.46) выяснился интересный момент.

А именно, по какой-то причине программисты Крипто-Про предполагают, что только JCP (точнее, провайдер с именем Crypto) может быть зарегистрирован в java.security в качестве провайдера, реализующего ГОСТ 28147-89 и имеющего зарегистрированный с этим провайдером сервис KeyGenerator “GOST28147”.

Если у вас в java.security зарегистрирован другой провайдер, имеющий сервис KeyGenerator “GOST28147” (например, в моем случае, BouncyCastle), и он зарегистрирован первым (с меньшим номером), чем Crypto, то при TLS хендшейке вы получите следующую ошибку:
WARNING: Недопустимый тип ключа.
java.security.InvalidKeyException: Недопустимый тип ключа.
at ru.CryptoPro.Crypto.Cipher.GostCipher.engineWrap(Unknown Source)
at ru.CryptoPro.Crypto.Cipher.Padding5Cipher.engineWrap(Unknown Source)
at javax.crypto.Cipher.wrap(DashoA13*..)
at ru.CryptoPro.ssl.gostTLS.e.a(Unknown Source)
at ru.CryptoPro.ssl.gostTLS.a.a(Unknown Source)
at ru.CryptoPro.ssl.a.a(Unknown Source)
at ru.CryptoPro.ssl.a.a(Unknown Source)
at ru.CryptoPro.ssl.K.k(Unknown Source)
at ru.CryptoPro.ssl.K.a(Unknown Source)
at ru.CryptoPro.ssl.s.a(Unknown Source)
at ru.CryptoPro.ssl.s.h(Unknown Source)
at ru.CryptoPro.ssl.s.startHandshake(Unknown Source)
...


Переместив в java.security ru.CryptoPro.Crypto.CryptoProvider «выше» другого провайдера, имеющего сервис KeyGenerator “GOST28147”, проблема была устранена.

В чем же причина?

Объяснение этому может быть следующее:

1)В JTLS для генерации ключа Крипто-Про не указывает явно провайдера. Скорее всего вместо метода javax.crypto.KeyGenerator.getInstance(“GOST28147”, “Crypto”).generateKey() используется javax.crypto.KeyGenerator.getInstance(“GOST28147”).generateKey(). Соответственно, Java выбирает “первого” провайдера – в моем случае BouncyCastle вместо Crypto, и в итоге создается “BouncyCastle-овский”объект, реализующий интерфейс javax.crypto.SecretKey, а не “Crypto-шный”

2)Где-то в недрах метода ru.CryptoPro.Crypto.Cipher.GostCipher.engineWrap (первая строчка стектрейса) Крипто-Про проверяет, что полученный ключ – нужного ему класса и в случае «несоответствия» выбрасывает java.security.InvalidKeyException

Доказать это без нарушения лицензионного соглашения нельзя, однако я уверен, что мое предположение верно.

Конечно же, проблему тривиально обойти (что и было сделано) – поместив в файле java.security провайдера ru.CryptoPro.Crypto.CryptoProvider выше всех других провайдеров, регистрирующих сервис KeyGenerator с алгоритмом “GOST28147”. Но все-таки хотелось бы, чтобы программисты Крипто-Про исправили ошибку.