| ||||
| ||||
| Доброе время суток! Не подскажете как воспользоваться Вашим криптопровайдером из программы, применяющей CAPICOM. Дело в том, что используемые алгоритмы выбираются путем констант типа CAPICOM_ENCRYPTION_ALGORITHM и описаны константы для RC, DES и т.д., но нет варианта ГОСТ :( | ||||
| Ответы: | ||||
| ||||
| Да действительно, ухитрились разработчики CAPICOM внести ложку в ... хорошую идею и реализация, пронумеровав алгоритмы шифрования. Действительно в варианте использования объекта EncryptedData ничего не получиться. Но в варианте EnvelopedData все работает и в этом можно убедиться, протестировав пример Platform SDK\Samples\WinBase\Security\Crypto\CAPICOM\vb\envelop Сделано сейчас это следующим образом. Если при использовании объекта EnvelopedData (а это аналог Low Level Message Functions из CryptoAPI 2.0) сертификаты получателей сообщений содержат ключи ГОСТ, автоматически алгоритм шифрования сообщения меняется на 28147. Можете проверить, используя утилиту dumpasn1. | ||||
| ||||
| То есть, при работе с CAPICOM, можно использовать только EnvelopedData? А EncriptedData и SignedData - нельзя? В большинстве случаев необходимо не только шифровать, но и подписывать передаваемые данные, а EnvelopedData.Encrypt этого не делает. Как быть? | ||||
| ||||
| Как раз с подписью все работает без проблем. Объект SignetData выбирает алгоритм ЭЦП в зависимости от сертификата. Будет сертификат с SHA1,RSA получится соответствующая подпись. Соответственно и ГОСТом. Сертификат с ГОСТом - подпись по ГОСТу. Проверить это легко. Все лежит здесь: http://www.cryptopro.ru/CryptoPro/pki/capicom.asp | ||||
| ||||
| И еще один вопрос. Можно ли как-нибудь обойти проблему с выбором сессионных ключей? То есть, чтобы разные сообщения шифровались на разных ключах, генерируемых отдельно. EnvelopedData и SignedData, как я понял, работают только с открытым ключом, указанном в сертификате. | ||||
| ||||
| Ну при подписи всегда используется секретный ключ. А для шифрования всегда автоматически вырабатывается сессионный, затем он экспортируется на ключе получателя. Да и в CAPICOM в Enveloped нет упоминания про сессионные ключи (как и в почте). | ||||
| ||||
| А вот Майкрософт неоднократно заявлял, что в CAPICOM 1.0 реализован пока только sha1 алгоритм хеширования (см. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0109D&L=CAPICOM&P=R807 ) - видимо он у них жестко задан константой и "из сертификата" не берется ... Может быть ваш CSP работает с CAPICOM лишь потому, что функции Вашего CSP "проглатывают" установки использовать sha1 алгоритм (проверено на CryptSignMessage с параметром HashAlgorithm структуры CRYPT_SIGN_MESSAGE_PARA установленным в: szOID_RSA_SHA1RSA, szOID_X957_SHA1DSA, szOID_OIWSEC_shaDSA, szOID_OIWSEC_shaRSA и проч.), а, скажем, MD5 отвергается как "Invalid algorithm specified". Какой уж в действительности хеш-алгоритм используется - вам виднее... Но работает :-) Осветите обстановку, плиз! | ||||
| ||||
| Действительно CAPICOM не имеет возможности указания алгоритма шифрования. Хуже дело обстоит с методом Encrypted. Алгоритмы шифрования перечислены. Но отдельно функции хеширования в CAPICOM нет. А метод Signed работает через CryptoAPI Low Level Message Functions. Вот на этом уровне функций анализируется состав сертификатов, используемых для подписи и если в них открытый ключ по ГОСТ, вместо SHA1 используется ГОСТ. На сервера http://www.cryptopro.ru/CryptoPro/test/dumpasn1.zip лежит утилита от Peter Gutman, которую можно пользовать для просмотра любых структур ASN.1 (сертификаты, PKCS#7 signed, enveloped, PKCS#10 request). Полезная вещь. | ||||
Nick