Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926  Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Не могли бы вы приложить сертификат nbki, который используете? Будем проверять. Отредактировано пользователем 8 апреля 2014 г. 14:11:29(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
В CSP существует возможность зашифровать на ключе подписи, а в JCP - нет (основные проверки две - первая, что ключ обмена, происходит от GostExchPrivateKey в методе init() класса KeyAgreement; а вторая, что параметры в закрытом ключе отправителя и открытом ключе получателя совпадают в doDHPhase класса закрытого ключа). Попробуйте Автор: s_Vace  Могу ли я попробовать запросить свой НБКИ, чтобы они мне прислали открытый сертификат получателя, чтобы он был exchange key? Отредактировано пользователем 8 апреля 2014 г. 14:16:13(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 05.03.2014(UTC)
Сообщений: 16
|
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Да, ваш ключ обмена представляется как объект GostExchPrivateKey и успешно передается в init() класса KeyAgreement, однако параметры закрытого ключа и открытого ключа отличаются. Если вы создадите свой закрытый ключ подписи, то он не пройдет в init() класса KeyAgreement. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 05.03.2014(UTC)
Сообщений: 16
|
Так...мне ответили, вот что: Ключ выпущенный на Ваше имя не должен быть exchange key и не используется в шифровании. Как уже говорилось Вам ранее, открытые сертификаты получателей используются только для шифрования. А открытый сертификат получателя значится как Signature. В общем не будут выпускать специально для меня открытый сертификат получателя.. Получается, с помощью JCP нельзя работать с этим нбки? Отредактировано пользователем 8 апреля 2014 г. 15:07:07(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Т.к. нужны идентичные параметры в открытом ключе получателя и закрытом ключе отправителя, а со стороны получателя ничего менять не будут (останутся параметры подписи вместо параметров обмена), то да - так использовать не удастся. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41  Сказала «Спасибо»: 4 раз
|
Добрый день!
Столкнулись с такой же проблемой при взаимодействии с НБКИ.
Подскажите, пожалуйста, если у сертификата получателя, на котором требуется зашифровать файл, следующие параметры:
Использование ключа:
Цифровая подпись
Неотрекаемость
Шифрование ключей
Шифрование данных
Дополнительное назначение ключа:
Email (1.3.6.1.5.5.7.3.4)
(1.2.643.6.13.1)
Пользователь Центра Регистрации (1.2.643.2.2.34.6)
Аутентификация клиента (1.3.6.1.5.5.7.3.2)
То зашифровать на нем через JCP возможно? Или должен быть еще какой-то параметр, касающийся согласования?
Если возможно, то чтобы зашифровать на нем сообщение, необходимо сгенерировать эфимерную пару и ключ согласования? с такими же параметрами?
У нас есть свой закрытый ключ. Мы аналогично описанному выше примеру пытались использовать его для симметричного шифрования, но на стороне получателя (НБКИ) сказали, что наш ключ только для подписи и не должен использоваться в шифровании.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Здравствуйте. Посмотрите пример PKCS7EnvEphTransport в samples-sources.jar/CMS_samples, в последнем дистрибутиве JCP 2.0 - он (пример) использует ключ обмена (!). В последнем JCP 2.0 есть также CAdES.jar с классом EnvelopedSignature (в пакете CAdES/enveloped того же samples-sources.jar, класс описан в CAdES-javadoc.jar) - он позволяет использовать как ключ обмена (будет получена структура key_transport), так и ключ подписи (структура key_agreement). Да, у вас, судя по всему, сертификат ключа обмена. Такой ключ может быть использован для согласования, но параметры ключей сторон должны совпадать. Отредактировано пользователем 20 мая 2015 г. 13:09:33(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
Спасибо! Пример посмотрю. А с версией JCP ниже 2.0 это возможно реализовать? Или какие-то особенности только в 2.0 появились? Т.к. 2.0 не сертифицирована мы её использовать не можем.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,926 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Автор: ThinkingAnna А с версией JCP ниже 2.0 это возможно реализовать? Можете адаптировать пример для 1.0.54. Он использует ключ обмена ГОСТ 34.10-2001 и создает key_transport. В 2.0 различные изменения - чтобы узнать о них, лучше посмотреть changelog в папке Doc дистрибутива. Отредактировано пользователем 20 мая 2015 г. 13:49:12(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
