| ||||
| ||||
| Установил carrier -> registry // Создаю keyset HCRYPTPROV prov; ::CryptAcquireContext(&prov, _T("the_container"), CP_DEF_PROV, type, CRYPT_NEWKEYSET); // == S_OK ::CryptReleaseContext(prov, 0); // создаю еще раз - возвращает S_OK, как будто он до этого не был создан // открываю криптопровайдера с контейнером ::CryptAcquireContext(&prov, _T("the_container"), CP_DEF_PROV, type, 0); // диалог - "Keyset does not exist" Вопрос: как создать keyset? P.S. С Microsoft’овскими провайдерами все Ok. | ||||
| Ответы: | ||||
| ||||
| Оказалось, что после создания keyset’a в него надо обязательно положить ключ. Зачем такие неудобства? Почему, когда я создаю контейнер, который уже существует, мне не возвращается ошибка NTE_EXISTS? Почему, когда ключ клонируется, не клонируется его вектор инициализации. Почему CBC не режим по-умолчанию для блочного ключа? Как можно работать с таким API? Основная цель создания Microsoft’ом Crypto API была предоставить возможность приложениям полиморфно работать с любыми криптопровайдерами, поддерживающими необходимые алгоритмы/протоколы. Т.е. логика приложения не должна зависеть от конретного криптопровайдера. С КриптоПро же все по-другому. Приходится специально затачивать код, чтобы обходится значительно урезанной нелогичной функциональностью. Зачем так сделано? Случайно ведь так сложно сделать. Я не понимаю... Чтобы для галочки написать "у нас MS-compatible CSP"? | ||||
| ||||
| Зачем так сразу много упреков. По-моему вы просто не разобрались. Вы хотите сказать, что Микрософтовский провайдер после CryptAcquireContext (..CRYPT_NEWKEYSET) делает долговременные ключи??? Посмотрите внимательно в документации как создаются ключи. Они создаются функцией CPGenKey The CPGenKey function generates a random cryptographic key or key pair. | ||||
| ||||
| Да, возможно не разобрался. Но проблема в том, что поведение КриптоПро CSP значительно отличается от того, что написано в MSDN и от поведения Microsoft’овских провайдеров в худшую сторону. Складывается впечатление, что криптопровайдер написан крайне небрежно. Это очень расстраивает. С Microsoft провайдером я могу создать keyset, не создавая в нем ключей. В КриптоПро это нельзя сделать - нужно обязательно создать в контейнере ключ. В чем причина такого ограничения? | ||||
| ||||
| По скольку мы используем в качестве ключевого носителя не только реестр (а например, смарт-карты), то для того чтобы создать контейнер в момент CryptAcquireContext необходим пароль или pin-код. Microsoft запрещает вывод диалогового окна с запросом пароля во время выполнения CryptAcquireContext, для того чтобы этот пароль можно было установить в SILENT режиме, через функцию CryptSetProvParam. Из этой ситуации создатели крипто-провайдеров выходят по разному, кто-то это правило нарушает, кто-то передает дополнительные параметры (pin) через ИМЯ контейнера. Мы просто не создаем этот контейнер при AcquireContext, Microsoft это не запрещает. У нас нигде не написано, что "MS-compatible CSP", у нас провайдер сделан в соответствии с интерфейсом CSP; и если Microsoft рекомендует не выводить окон, то мы стараемся этого не делать. | ||||
Maxim Egorushkin