Добрый день.
Начну с того, что подписывать хэш само по себе не очень хорошая практика. Если позволяет задача - подписывайте содержимое, доверив вычисление хэша автоматике и избавитесь от кучи проблем. Поверьте, экономия на пересылке файла не стоит Ваших нервов. Исключение составляют интерфейсы вроде Питона, где подписать хэш - единственный способ.
Автор: Михаил AAAAAA Столкнулись с такой же проблемой. Есть сертификат с ключами по алгоритму RSA длиной 2048 бит.
"с такой же проблемой" - самое худшее описание ситуации, просто по поверхностному проявлению Вы не можете знать заранее, что проблема такая же. С прошлых сообщений темы прошло 2 года и актуальные версии плагина и криптопровайдера изменились.
Пожалуйста, сообщите больше информации о своем случае, как минимум, как в сообщениях выше: версия плагина, версия криптопровайдера, криптопровайдер, в сертификате - открытый ключ по какому алгоритму? Дополню новшествами 5.0: установлен ли компонент КриптоПро RSA криптопровайдер? ключ RSA хранится в контейнере от Майкрософт или в контейнере от КриптоПро?
Автор: Михаил AAAAAA Используем следующий код: ...
Результат - генерируется ошибка (exception) "Указан неправильный алгоритм. (0x80090008)".
С алгоритмом хэширования CADESCOM_HASH_ALGORITHM_SHA1 и этим же сертификатом ошибок нет и подпись генерируется правильно. Хотелось бы решение с алгоритмами sha-256 и sha-512.
Поясню немного общую ситуацию, если еще кто будет задаваться подобными экспериментами.
Для алгоритма гост (по крайней мере, в стандартах гост-94,гост-2001,гост-2012, так как гост-2015 я подробно не смотрел еще) жестко закреплено соответствие алгоритма ключа и алгоритма хэша. Подписать хэш гост-2012 получится только ключом гост-2012, причем только соответствующей длины. Причина в том, что подписание гост не использует шифрование хэша при подписании, а берет случайное число определенной длины и вычисляет с его участием "проверочное значение" такой же длины - вместе они составляют RAW подпись. С другим алгоритмом исходного хэша процедура вычисления "проверочного значения" технически не сработает (параметры алгоритма разные). Плюс есть ограничения регулятора, касающиеся использования "уже ненадежных" алгоритмов хэша (которые можно подобрать на современных компьютерах за достаточно короткое время).
В случае ключа RSA алгоритм хэша не фиксирован - при подписании значение хэша шифруется ключом и технически нет особой разницы что именно и какой длины зашифровано. Однако нужно понимать, что ключи и хэши меньше определенной длины использовать не получится, так как они уже признаны нестойкими и Microsoft CryptoApi их отклонит еще до самой процедуры подписания. Это справедливо если использовать интерфейсы Майкрософт - CryptoApi или CAPICOM.
Что касается подписания зарубежными алгоритмами через интерфейсы КриптоПро (cadescom), то с этим еще более сложная ситуация. В интернете можно найти много старого кода для КриптоПро 3.6, где не моргнув глазом в высокоуровневом вызове CryptoApi указывали алгоритм SHA1, сертификат гост-2001 и получали подписи.... гост-2001. Другими словами, раньше криптопровайдер КриптоПро не поддерживал зарубежные алгоритмы и использовал "магию" чтобы проигнорировать зарубежный алгоритм хэша и перейти на вычисление алгоритма гост, согласно сертификату.
С подписанием хэша в плагина все еще интереснее: при вызове CryptoApi сначала открывается дескриптор контейнера, потом на его основе открывается дескриптор хэша. Другими словами, либо нужно знать каким ключом хэш будете подписывать либо придется копировать значение хэша в новый объект хэша, когда определитесь с ключом. Плагин же позволяет создать HashedData и потом их подписать произвольно, то есть вот вы установили значение хэша, а потом при подписании где-то там внутри есть еще одна операция извлечения значения хэша и установки хэша в новый объект хэша (новый создан на основе дескриптора нужного контейнера).
По такой причине, без детального изучения проблемы (как минимум знания точных версий плагина и криптопровайдера) нельзя гарантировать какой именно криптопровайдер получил Ваш вызов с SHA256 и выдал ошибку о неправильном параметре. Есть вероятность, что как раз сработала "магия", но в этот раз автоисправление параметров привело к ошибке. В итоге, тестировать код для cadescom с указанием зарубежных алгоритмов не очень хорошая идея.
Однако если Вам нужно не просто для тестирования, а "всерьез", но недавно появился "свет в конце тоннеля". С версией 5.0 в КриптоПро добавился необязательный компонент (RSA криптопровайдер), который позволяет использовать контейнер КриптоПро для хранения ключей RSA. Для его работы нужно запустить установщик КриптоПро, отметить компонент (RSA криптопровайдер), установить, перезагрузиться. Затем экспортировать ключ RSA из контейнера Майкрософт, импортировать в контейнер КриптоПро (то есть средствами КриптоПро с привязкой уже к КриптоПро RSA криптопровайдеру). Если все получилось правильно, контейнер будет виден в КриптоПро. На новых версиях по идее сертификат также привязывается автоматом, на первых версия 5.0 надо привязать вручную. Если используете интерфейсы КриптоПро для подписания, ряд проблем может быть исправлен переходом на этот КриптоПро RSA криптопровайдер.