| 12.10.2005 21:52:48 | OID обмена для подписи | | Ответов: 13 |
|
 DimaP | | |
|
| В SDK для CryptoPro 3.0 указано "OID_DH128Var_1 "1.2.643.2.2.33.1" Параметры P,Q,A алгоритма Диффи-Хеллмана на базе экспоненциальной функции, вариант 1", можно ли на ключе с такими параметрами получать ЭЦП ? |
| |
Ответы:
|
| 13.10.2005 12:23:29 | Василий |
|
| По-любому лучше использовать ГОСТ Р 34.10-2001 и соответствующие ему наборы параметров - 1.2.643.2.2.35.x |
|
|
| Вопрос не в том 94 года алгоритм использовать или 2001, а в том что там не написано что на этих параметрах можно получать ЭЦП. Вот я и спросил, на самом деле можно или нет? |
|
| 13.10.2005 18:20:10 | Василий |
|
| Будем рассуждать логически - в документации написано, что этот ОИД - для алгоритма Диффи-Хеллмана. Если на ключе с таким ОИДом можно делать подпись, то это не более чем недокументированная возможность, если не сказать - нарушение условий эксплуатации CSP. Оно Вам надо? |
|
|
| Вы так спрашиваете как буд-то это я разработчик этого CSP :-) Мне все равно так или эдак, я спрашиваю как есть на самом деле, для того чтобы узнать возможна ли такая ситуация что при этих параметрах получать ЭЦП. |
|
| 14.10.2005 10:58:03 | Василий |
|
Раз всё равно - почему бы не взять для ЭЦП явно предназначенный для ЭЦП ОИД "1.2.643.2.2.32.х"?
|
|
|
| Зачем так вилять и уходить от ответа на вполне конкретный вопрос "может это CSP или нет?", не пойму. Вместо того чтобы сказать да или нет, вы отвечаете вопросом на вопрос. В данном случае мне будет проще на практике проверить может ваш CSP это или нет. Не понятно зачем так темнить когда это все легко проверить. Я думал форум призван облекчать жизнь разработчикам, а не усложнять их. |
|
| 17.10.2005 9:27:51 | Kirill Sobolev |
|
Представьте, Вы купили автомобиль и после этого начинаете задавать заводу или сервисцентру вопрос "А если в него залить солярки, снять резину и пустить по рельсам, он сможет ездить как тепловоз? Это ведь легко проверить!". Как Вы думаете, что Вам ответят?
CSP - это продукт, предназначенный для выполнения определенных задач при вполне определеных условиях. Если с этим возникают проблемы, то мы по мере возможностей стараемся помочь. Но эксперименты типа "а чтобы еще такого сделать с CSP" не проводятся, и соотвественно их результаты предсказаны быть не могут. |
|
|
Очень удивляют ваши ответы.
Если в консоли настроки CryptoPro 3.0 указать во вкладке алгоритмы, в параметрах алгоритма Деффи-Хелмана, любой параметр, кроме "... параметр обмена по умолчанию", то вновь создаваемы ключ обмена AT_EXCHANGE будет создан именно с этими параметрами, а не с параметрами подписи (те что устанавливаются строчкой выше). И если учесть, что в основном пользователь пользуется (для почты) сертификатом именно ключа AT_EXCHANGE (то есть в том числе и подписывает почтовые сообщения), то очевидно что на параметрах, которые описаны в SDK как "только для обмена по Деффи-Хелману и ничего более", будут получены ЭЦП и на них же ЭЦП будет проверятся.
После этого вы заявляете, что это все не документированная, не тестированные возможности??? |
|
| 18.10.2005 10:34:49 | Василий |
|
1. Покажите, плиз, место, где написано "...и ничего более".
2. Понятно, что ключу AT_KEYEXCHANGE задаются параметры для алгоритма Диффи-Хеллмана. Основное назначение этого ключа - шифрование сессионного ключа, используемого при шифровании данных. То, что этот ключ можно использовать для ЭЦП - на усмотрение разработчиков CSP и приложения, которое использует ключ и сертификат. Есть приложения, которые явно не разрешают для подписи использовать ключ AT_KEYEXCHANGE. Есть приложения, которые разрешают или не разрешают это действие в зависимости от параметров сертификата. |
|
|
Очень удивляют ваши ответы.
Если в консоли настроки CryptoPro 3.0 указать во вкладке алгоритмы, в параметрах алгоритма Деффи-Хелмана, любой параметр, кроме "... параметр обмена по умолчанию", то вновь создаваемы ключ обмена AT_EXCHANGE будет создан именно с этими параметрами, а не с параметрами подписи (те что устанавливаются строчкой выше). И если учесть, что в основном пользователь пользуется (для почты) сертификатом именно ключа AT_EXCHANGE (то есть в том числе и подписывает почтовые сообщения), то очевидно что на параметрах, которые описаны в SDK как "только для обмена по Деффи-Хелману и ничего более", будут получены ЭЦП и на них же ЭЦП будет проверятся.
После этого вы заявляете, что это все не документированная, не тестированные возможности??? |
|
|
"Будем рассуждать логически - в документации написано, что этот ОИД - для алгоритма Диффи-Хеллмана. Если на ключе с таким ОИДом можно делать подпись, то это не более чем недокументированная возможность, если не сказать - нарушение условий эксплуатации CSP. Оно Вам надо?"
Вы сами назвали возможность подписать с OIDом (напрример "OID_DH128Var_1 "1.2.643.2.2.33.1" Параметры P,Q,A алгоритма Диффи-Хеллмана на базе экспоненциальной функции, вариант 1") для алгоритма Диффи-Хеллмана "недокументированная возможность, если не сказать - нарушение условий эксплуатации CSP".
Теперь вы говорите что это все на усмотрение приложений использующих CrytoAPI.
|
|
|
Кстати есть ошибка в документе SDK 3.0:
"OID_CipherVar_Default "1.2.643.2.2.31.0" Узел замены функции алгоритма шифрования, дефолтовый вариант. В качестве дефолтового используется узел замены варианта "Верба-О"
"OID_CryptTest "1.2.643.2.2.31.0" Тестовый узел замены алгоритма шифрования" |
|
| 18.10.2005 16:31:14 | Василий |
|
Если Вы - разработчик приложения, использующего криптографические функции, то лучше для ЭЦП использовать ключи и OID-ы, предназначенные для ЭЦП, а для шифрования ключей по схеме Диффи-Хеллмана использовать ключи и OID-ы, предназначенные для этого действия. И это правильно (и рекомендуется). Если приложение уже готовое, то, понятно, поменять не получится - оно будет работать так, как захотели разработчики.
За ошибку спасибо - учтём. |
|
