| ||||
| ||||
| Используем PKI, а то бишь: получаем сертификат пользователя и шифруем все с помощью CryptEncryptMessage. Расшифровываем все с помощью, естественно, CryptDecryptMessage. Все хорошо, кроме одного но - CryptDecryptMessage принимает на вход хендл на хранилище сертификатов. И при большом объеме зашифрованных данных возникают проблемы - 10 Мб расшифровывались около 15 минут... :о( Как я понимаю, перебираются все сертификаты в поиске нужного. Как избавиться от этого перебора? Посоветуйте... Есть ли какие-нибудь другие механизмы шифрования/расшифрования, где при расшифровке использовался бы конкретный контекст сертификата... | ||||
| Ответы: | ||||
| ||||
| Померьте время зашифрования-расшифрования файла такого же размера при использовании программы CryptCP - http://www.cryptopro.ru/CryptoPro/products/command.asp | ||||
| ||||
| Василий, в том-то и дело, что тот же cryptcp для расшифрования требует один сертификат! Так как расшифровывать данные, передавая только лишь сертификат, а не хендл на хранилище? | ||||
| ||||
| Программой cryptcp я померил время - скорость мне понравилась. Кстати, 15 минут в моих тестах - это субъективно, потому как потом шел разбор полученных данных. | ||||
| ||||
| Если Вам хочется использовать именно CryptDecryptMessage, то сделайте временное хранилище в памяти с единственным нужным вам сертификатом - его и передавайте. А можно использовать функции более низкого уровня - CryptMsg*. Хотя, непонятна зависимость времени от количества сертификатов - информация о получателе есть в сообщение, а поиск в хранилище действие довольно таки быстрое... | ||||
| ||||
| Кирилл, спасибо, дали ответ - информация о получателе содержится в сообщении. И тогда встречный вопрос - как сделать так, чтобы не включать информацию о получателе в шифрованное сообщение? Или против стандартов не пойдешь? ;) | ||||
| ||||
| Ну почему - CryptEncrypt/CryptDecrypt. Но тогда придется как-то генерить и передавать ключи самостоятельно, т.к. в сообщении помимо информации о получателе содержится еще и ключ, которым было зашифровано и параметры шифрования (вектор инициализации например). | ||||
| ||||
| Кирилл, Вы опять неволей затрагиваете интересующие меня вопросы - "...вектор инициализации..." Возможно ли средствами CryptoAPI варьировать использованием различных режимов сцепления блоков шифртекста, например, вместо простейшего режима электронной кодовой книги использовать режим обратной связи по выходу? И еще такой вопрос - функция режимов сцепления, как я понимаю, должна поддерживаться CSP? И какие режимы использует CryptoPRO? | ||||
| ||||
| Разумеется, можно использовать любой из поддерживаемых режимов (вот цитата из нашей документации http://www.cryptopro.ru/CryptoPro/test/csp_2_0.chm): Параметр KP_MODE (функции CryptSetKeyParam). Режим шифра. Задается величиной DWORD. Передаётся функции через буфер pbData. В следующем списке приведены режимы шифрования, определённые в настоящее время: CRYPT_MODE_ECB - ГОСТ 28147-89 режим простой замены; CRYPT_MODE_OFB - ГОСТ 28147-89 режим гаммирования; CRYPT_MODE_CFB - ГОСТ 28147-89 режим гаммирования с обратной связью. CRYPT_MODE_CBC - блочный шифр с обратной связью; Но, при этом придётся самостоятельно генерить сессионный ключ и менять его параметры, а потом передавать его получателю. Полный текст примера - в http://www.cryptopro.ru/CryptoPro/forum/myforum.asp?q=4, а также http://www.cryptopro.ru/CryptoPro/test/sample2_0.zip | ||||
| ||||
| Василий, спасибо Вам большое. Товарищи, у меня еще к вам вопрос. "1.3.6.1.5.5.7.3.2" - спуск для алгоритма ГОСТ Р 34.10-94. А какой у 2001 ГОСТ-а? | ||||
| ||||
| "1.3.6.1.5.5.7.3.2" - "Проверка подлинности клиента" - это OID EKU (Extended Key Usage, в русском переводе "Улучшенный ключ") сертификата, предназначенного для функционирования TLS-клиента. При этом алгоритм ключа сертфиката может быть разным - как ГОСТ (..94 или ..2001), так и RSA. | ||||
| ||||
| Василий, спасибо, что вывели меня из заблуждения. :о) А может кинуть ссылочку на описание всех таких OID? И еще вопрос... Я формирую запрос на сертификацию из Lotus Notes, используя CryptoPRO. Откуда я уж отрыл "1.3.6.1.5.5.7.3.2" - я не помню уже. Но факт - мне не удается получать сетритифакы под 2001 ГОСТ... Думал, что дела в этом самом OID, но... Подскажите, в чем может быть проблема. | ||||
| ||||
| Это один из стандартных OID-ов EKU, зарегистрированных в Windows. Ещё примеры - Защищенная электронная почта -1.3.6.1.5.5.7.3.4, Проверка подлинности сервера - 1.3.6.1.5.5.7.3.1 По второму: уточните, где проичодит ошибка: - при формировании запроса на сертификат - при изготовлении сертификата по запросу - при установке сертификата - при работе с сертификатом | ||||
| ||||
| Василий, ошибки не происходит. Формирование запроса на сертификацию: Set XEnroll = CreateObject("CEnroll.CEnroll.1") XEnroll.ProviderType = 2 XEnroll.ProviderName = "Crypto-Pro Cryptographic Service Provider" ’ XEnroll.addCertTypeToRequest("ExchangeUser") XEnroll.addCertTypeToRequest("Пользователь") XEnroll.KeySpec=1 strName = "2.5.4.6" strValue = "UZ" Call Xenroll.addNameValuePairToSignature(strName, strValue) ’AT_KEYEXCHANGE=1; ’AT_SIGNATURE=2; Usage = "1.3.6.1.5.5.7.3.2" PKCS10 = XEnroll.createPKCS10(strDN, usage) Container = XEnroll.ContainerName Store = XEnroll.RequestStoreName StType = XEnroll.RequestStoreType Код написан на LotusScript. Запрос на сертификацию формируется для 94-того ГОСТ-а. А как быть с 2001? | ||||
| ||||
| XEnroll.ProviderType = 75 XEnroll.ProviderName = "Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider" | ||||
| ||||
| Василий, спасибо большое за помощь по этому и по другим вопросам... :о) За вклад в мое просвещение... :о) | ||||
Евгений