Если речь идет о возможности экспорта сессионного ключа, то должен отметить, что провайдеры от Microsoft изначально обладают такой возможностью. Доступность этой возможности можно проверить путем экспорта сертификата с ассоциированным с ним секретным ключом. Криптопровайдеры от Microsoft всегда позволяют сделать экспорт сертификата (*.p7b) вместе с его секретным ключом. Криптопровайдеры от других производителей не позволят сделать подобное.
Кроме того, в описываемой в приведенной Вами статье используется формат BLOB-а именно для Microsoft. Для других производителей он, естественно, не подойдет. Proprietary code
валится
::CryptGenKey(hProv, CALG_RC4, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey)
с кодом 0x8008022 — поставщик не смог выполнить действие, поскольку контекст был получен как «тихий»
Что не так?
VS>валится VS>::CryptGenKey(hProv, CALG_RC4, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey) VS>с кодом 0x8008022 — поставщик не смог выполнить действие, поскольку контекст был получен как «тихий» VS>Что не так?
VS>Это первый пример из статьи где шифруется текст.
действительно, падает. что делать?
и что за функция Error()? что надо подключить, чтоб оно компилировалось хотя бы?
Здравствуйте, Юрий Николаев, Вы писали:
ЮН>В статье рассказывается об использовании Crypto API — API шифрования и работы с цифровой подписью в Windows.
Все это дивно, но виндовсный Crypto API — черный ящик, спроектированный по принципу "нажми на кнопку, получишь результат". Нередко стоит задача сделать совместимую реализацию чего-нибудь криптографического, когда на одном конце стоит венда с CryptoAPI, а на другом — не винда и при этом все форматы/протоколы известны.
К сожалению, про CryptoAPI нигде не документированно, в каком виде из него можно извлекать те или иные данные. Например, вы использыете DHE, чтобы получить сессионный ключ, а в каком виде он оттуда вылазит, недокументированно. Известно лишь, что их можно извлечь в виде пригодном, чтобы назад засунуть в тот же CryptoAPI. Но если у вас на другом конце не CryptoAPI, вам это знание мало чем поможет.
Кроме того, нигде не документированно, на какие ограничения (например, по длинне ключей) вы можете рассчитывать.
А поскольку требование совместимости с альтернативной реализацией рано или поздно может появиться, то использовать CryptoAPI в новых проектах несколько рискованно, вы оказываетесь навсегда привязаны к венде.
все, разобрался. вместо "CryptGenKey(hProv, CALG_RC4, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey)"
следует писать "CryptGenKey(hProv, CALG_RC4, 0, &hSessionKey)", тогда все нормально шифруется и пример работает.
Здравствуйте, yudinetz, Вы писали:
Y>все, разобрался. вместо "CryptGenKey(hProv, CALG_RC4, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey)" Y>следует писать "CryptGenKey(hProv, CALG_RC4, 0, &hSessionKey)", тогда все нормально шифруется и пример работает.
Вообще-то в этом параметре надо длину ключа передавать в старшем слове, при нуле берётся дефолтное, а оно от версии провайдера зависит. Плюс флаги разные в младшем слове — по желанию.
"Нормальные герои всегда идут в обход!"
