Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

3 Страницы123>
Опции
К последнему сообщению К первому непрочитанному
Offline HelenKlimova  
#1 Оставлено : 17 июля 2014 г. 8:50:34(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Добрый день!

Возникла проблема.
Выдается ошибка на doPhase(publicKey,true) - java.security.InvalidKeyException: Несоответствие параметров

Почитала темы на форуме, попробовала сделать, что советуют. Есть неутешительные результаты.

Алгоритм нашего ключа - GOST3410DH
CryptoPro Gost PrivateKey (GOST3410DH) with parameters: 1.2.643.2.2.98
ru.CryptoPro.JCP.params.EllipticParamsSpecDH: 1.2.643.2.2.36.0
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1

Алгоритм ключа получателя - ECGOST3410
EC Public Key
X: 42cce81e7f2d3cbeea0cf537ede481c3e8d3b1600c64f8b4ed73ecf69f569794
Y: dbf0185c320455a5accade7c0a10a85550e3ede520c58fb2b136c4192053239d

digestParamSet - 1.2.643.2.2.30.1
encryptionParamSet - null
publicKeyParamSet - 1.2.643.2.2.35.1

При попытке приведения ключа получателя к GostPublicKey, естественно, выдается ошибка org.bouncycastle.jce.provider.JCEECPublicKey cannot be cast to ru.CryptoPro.JCP.Key.GostPublicKey

Есть ли какие-то варианты решения проблемы? Понятное дело, получатель не будет выпускать отдельный ключ ради нас.
Offline Евгений Афанасьев  
#2 Оставлено : 17 июля 2014 г. 9:18:11(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 4,003
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 714 раз в 674 постах
Автор: HelenKlimova Перейти к цитате
При попытке приведения ключа получателя к GostPublicKey, естественно, выдается ошибка org.bouncycastle.jce.provider.JCEECPublicKey cannot be cast to ru.CryptoPro.JCP.Key.GostPublicKey


Добрый день.
Использовать либо bouncycastle, либо JCP.

Offline HelenKlimova  
#3 Оставлено : 17 июля 2014 г. 18:44:56(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Автор: afev Перейти к цитате
Автор: HelenKlimova Перейти к цитате
При попытке приведения ключа получателя к GostPublicKey, естественно, выдается ошибка org.bouncycastle.jce.provider.JCEECPublicKey cannot be cast to ru.CryptoPro.JCP.Key.GostPublicKey


Добрый день.
Использовать либо bouncycastle, либо JCP.


Прошу прощения, села на другой комп, где только крипто-про
Так вот, используем JCP.

GOST3410 - ключ получателя
GOST3410DH - наш
ru.CryptoPro.JCP.Key.GostPublicKey
CryptoPro Gost PrivateKey (GOST3410DH) with parameters: 1.2.643.2.2.98

для нашего приватного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpecDH: 1.2.643.2.2.36.0
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1

для публичного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpec: 1.2.643.2.2.35.1
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1

Все равно возникает ошибка на doPhase(publicKey,true) - java.security.InvalidKeyException: Несоответствие параметров

Это возможно из-за того, что ru.CryptoPro.JCP.params.EllipticParamsSpec разные у наших сертификатов?

На другой паре - публичный ключ чужой + закрытый наш все работает.

Непонятно, что делать в случае с ошибкой. Ключ они не будут выпускать для нас. Возможны ли какие-то обходные пути?
Offline Евгений Афанасьев  
#4 Оставлено : 17 июля 2014 г. 20:21:01(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 4,003
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 714 раз в 674 постах
Автор: HelenKlimova Перейти к цитате

для нашего приватного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpecDH: 1.2.643.2.2.36.0
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1

для публичного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpec: 1.2.643.2.2.35.1
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1


Параметры EllipticParams в ключах не совпадают - для ключа обмена параметр должен быть 1.2.643.2.2.36.0, а JCP поддерживает согласование ключей только с такими параметрами.

Отредактировано пользователем 17 июля 2014 г. 20:22:53(UTC)  | Причина: Не указана

Offline HelenKlimova  
#5 Оставлено : 18 июля 2014 г. 6:25:58(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Автор: afev Перейти к цитате
Автор: HelenKlimova Перейти к цитате

для нашего приватного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpecDH: 1.2.643.2.2.36.0
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1

для публичного ключа
ru.CryptoPro.JCP.params.EllipticParamsSpec: 1.2.643.2.2.35.1
ru.CryptoPro.JCP.params.DigestParamsSpec: 1.2.643.2.2.30.1
ru.CryptoPro.JCP.params.CryptParamsSpec: 1.2.643.2.2.31.1


Параметры EllipticParams в ключах не совпадают - для ключа обмена параметр должен быть 1.2.643.2.2.36.0, а JCP поддерживает согласование ключей только с такими параметрами.


Спасибо, мы примерно так и думали, что проблема может быть в разных параметрах.
Возможен ли какой-то выход? В какую сторону искать?
Offline HelenKlimova  
#6 Оставлено : 11 декабря 2014 г. 7:25:13(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Добрый день!

Прошло уже несколько месяцев со времени возникновения проблемы, а выход так и не найден.
Возможно ли все-таки как-то решить данную проблему? Шифровать в jcp на чужой сертификат, если какой-то параметр в их сертификате не совпадает с параметром нашего?
Криптопровайдер партнера - Сигнал-ком. В их сертификате в использовании ключа по идее есть все, что нужно: "Цифровая подпись, Неотрекаемость, Шифрование ключей, Шифрование данных, Согласование ключей (f8)".

Будем благодарны за любую помощь.
Offline Максим Коллегин  
#7 Оставлено : 11 декабря 2014 г. 7:57:24(UTC)
Максим Коллегин

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,396
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 37 раз
Поблагодарили: 719 раз в 623 постах
Может все-таки партнеры сделают ключ обмена, а не подписи?
Знания в базе знаний, поддержка в техподдержке
Offline HelenKlimova  
#8 Оставлено : 11 декабря 2014 г. 14:51:13(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Автор: maxdm Перейти к цитате
Может все-таки партнеры сделают ключ обмена, а не подписи?

Это вряд ли, они работают со многими другими компаниями и утверждают, что проблем ни у кого нет.

ru.CryptoPro.JCP.params.EllipticParamsSpec: 1.2.643.2.2.35.1 - это параметр ключа подписи?

В сертификатах вроде бы у всех прописано одно и то же. Со всеми остальными партнерами шифрование работает, с ними - нет. Параметры у других не смотрели, но раз работает, должно быть все нормально.

То есть получается, если они не меняют сертификат, то на имеющийся в крипто-про jcp шифровать не получится вообще никак?
Offline Станислав Смышляев  
#9 Оставлено : 11 декабря 2014 г. 16:25:50(UTC)
Станислав Смышляев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 10.04.2013(UTC)
Сообщений: 186
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 81 раз в 62 постах
Добрый день!

В JCP 1.0, как и в версиях CSP 3.x стоит явное ограничение на использование ключей обмена только с параметрами 1.2.643.2.2.36.0 и 1.2.643.2.2.36.1. Данное ограничение было связано с позицией регулирующих органов (13 лет назад).

Теперь криптографическим сообществом все параметры решено принимать применимыми для всех совместимых алгоритмов - поэтому в CSP 4.0 и в новых версиях JCP 2.0 и JCSP ограничений накладываться не будет – в частности, можно будет создавать шифрованные сообщения с использованием сертификата получателя с параметрами ...35.1.
С уважением,
Станислав Смышляев, к.ф.-м.н.,
Заместитель генерального директора ООО "КРИПТО-ПРО"
Техническую поддержку оказываем здесь.
Наша база знаний.
thanks 1 пользователь поблагодарил Станислав Смышляев за этот пост.
HelenKlimova оставлено 11.12.2014(UTC)
Offline HelenKlimova  
#10 Оставлено : 11 декабря 2014 г. 17:07:50(UTC)
HelenKlimova

Статус: Активный участник

Группы: Участники
Зарегистрирован: 10.06.2014(UTC)
Сообщений: 65
Российская Федерация

Сказал(а) «Спасибо»: 5 раз
Автор: svs Перейти к цитате

Теперь криптографическим сообществом все параметры решено принимать применимыми для всех совместимых алгоритмов - поэтому в CSP 4.0 и в новых версиях JCP 2.0 и JCSP ограничений накладываться не будет – в частности, можно будет создавать шифрованные сообщения с использованием сертификата получателя с параметрами ...35.1.


Это хорошо. Подскажите пожалуйста, известен ли срок выхода новой версии, которая будет позволять создавать шифрованные сообщения с параметрами ..35.1? У нас сейчас версия 2.0.37538, на ней не работает.

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (2)
3 Страницы123>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.