| ||||
| ||||
Пожалуйста, поясните, как средствами CAPICOM можно шифровать-дешифровать данные, используя криптопровайдер КриптоПро CSP. Все, что я смог - это понять, как шифруются данные при помощи: EncryptedData.Algorithm.KeyLength EncryptedData.Algorithm.Name EncryptedData.SetSecret() EncryptedData.Content EncryptedData.Encrypt; Но ведь здесь я не делаю никакой привязки к криптопровайдеру!!! А нужно шифровать, используя КриптоПро CSP. Или я неправильно что-то понимаю? Подскажите, с чего начать.. | ||||
Ответы: | ||||
| ||||
Использовать КриптоПро CSP в EncryptedData не получится, т.к. алгоритмы жестко прошиты в CAPICOM_ENCRYPTION_ALGORITHM. Шифровать можно только в EnvelopedData, где алгоритм определяется по сертификату адресата. | ||||
| ||||
А есть ли на где-нибудь примеры использования CAPICOM с привязкой к КриптоПро CSP ? | ||||
| ||||
Работа с CAPICOM SingedData/EnvelopedData для КриптоПро СSP ничем не отличается от работы для других провайдеров. Поэтому подойдет любой пример из Platform SDK или MSDN | ||||
| ||||
мда... "алгоритм определяется по сертификату адресата" - или я чего-то не понимаю, или... В сертификате прописан только алгоритм открытого ключа + алгоритм подписи саго сертификата. Для EnvelopedData нужен симметричный алгоритм, а о нем там ровным счетом ничего не сказано. Кроме того, CAPICOM не позволяет выбрать CSP - таким образом можно работать только с дефолтным RSA (=1) провайдером. Или все-таки...? | ||||
| ||||
Выбирается так : если ключ гостовый, то используется ГОСТ 28147, если нет - то тот, что прописан в поле "Алгоритм". CAPICOM произвольный алгоритм выбрать не дает, согласен, это его большой недостаток. | ||||
| ||||
Бррр! Что такое “поле алгоритм"? Если имеется в виду алгоритм указанный для ключа сертификата, то это очевидно ассиметричный алгоритм (ГОСТ Р 34.10-94, например). В сертификате _нет_ никакого упоминания о симметричном алгоритме (да и не зачем ему там быть), соответственно CAPICOM неоткуда взять эту информацию - для этого у EnvelopedData есть свойство Algorithm (может оно и имелось в виду?). Однако множество поддерживаемых CAPICOM алгоритмов ограничено и _не включает_ ГОСТ! На самом деле я сам долгое время пытался написать универсальный код, работающий с любыми возможными алгоритмами, и пришел к выводу, что в CryptAPI этого сделать невозможно… CAPICOM этот вывод только подтверждает. P.S.: Если кто-то все же знает, как это сделать – поделитесь, plz! | ||||
| ||||
Попробовал сделать EnvelopedData на ГОСТ’е через CAPICOM - получилось :) Теперь я в непонятках: 1. Откуда CAPICOM знает тип/имя CSP? (можно конечно поэнумерить CSP в поисках того, кто поддерживает алгоритм открытого ключа, указанного в сертификате, но... а если таких много?) 2. Откуда CAPICOM знает тип алгоритма (можно конечно поэнумерить и взять первый попавшийся) 3. Откуда CAPICOM знает как выгрузить AlgorithmIdentifier для выбранного симметричного алгоритма? (см. мою ветку http://www.cryptopro.ru/CryptoPro/forum/myforum.asp?q=955) P.S.: Я знаю, что CAPICOM использует CryptMsgOpenTo(De/Enc)Code, так что "CAPICOM" в моем вопросе можно читать как "CryptoAPI". | ||||
| ||||
Кажется я понял, как это все работает - CryptoAPI и CAPICOM здесь ни причем (как я и думал, никакой универсальностью здесь и не пахнет). Итак: Есть в составе CryptPro CSP несколько замечательных DLL: 1. cpadvai.dll (модуль исправления функционирования advapi32) 2. cpcertocm.dll (модуль исправления функционирования certocm.dll) 3. cpcrypt.dll (модуль исправления функционирования crypt32) 4. cpintco.dll (модуль исправления функционирования inetcomm) 5. cpwinet.dll (модуль исправления функционирования wininet.dll) Это ни что иное, как хуки для соответствующих системных dll. То, что нас интересует - это cpcrypt.dll При помощи хука в тело CryptMsgOpenToDecode помещается инструкция перехода в тело cpcrypt.dll, в коде которой как раз и обрабатывается случай использования ГОСТ’овых алгоритмов. CAPICOM находясь в полной уверенности, что EnvelopedData будет собран на M$ RSA провайдере с симметричным алгоритмом RSA RC2 (или то, что вы указали в EnvelopedData.Algorithm) вызывает CryptMsgOpenToDecode и... получает PKCS7 EnvelopedData с использованием ГОСТ 28147. Думаю, что в коде CryptPro просто анализируются сертификаты в Recipients и, в зависимости от них, выбирается либо ГОСТ или выполнение отпинывается обратно в Crypt32... Как говорится - опа! Таким вот образом, команда разработки CryptoPro "научила" CryptMsgOpenTo(De/En)code (а значит и CAPICOM) работать с ГОСТ алгоритмом... Вопрос: по несчастливому стечению обстоятельств я не могу использовать ни CAPICOM ни даже low-level message API в CryptAPI, но хочу использовать CryptoPro CSP - как мне это сделать? Уточняю: научите меня, plz, как правильно сгенерировать сессионный ключ (IV, salt value или что там еще), экспортировать его из CSP (agreed key и т.д.), собрать AlgorithmIdentifier (_очень_ интересуют параметры шифрования) и закатать все это в RecpientInfo. Спасибо :) | ||||
| ||||
Ну тогда Вам только остается вызывать йункции провайдера напрямую. Их описание можете посмотреть http://www.cryptopro.ru/CryptoPro/test/csp_2_0.chm | ||||
| ||||
Ну тогда Вам только остается вызывать йункции провайдера напрямую. Их описание можете посмотреть http://www.cryptopro.ru/CryptoPro/test/csp_2_0.chm | ||||