ацтой :-/

Хэш-значение не хранится в сообщении, поэтому вытащить путём декодирования всё равно не получится.

Саму подпись можно достать и проще: CryptMsgGetParam(CMSG_ENCRYPTED_DIGEST). А вот расшифровать в случае с ГОСТовыми подписями (да и любыми Эль-Гамаль-подобными) не получится. Для RSA-подписи это сделать можно, только я боюсь в CryptoAPI это будет нетривиальной задачей, т.к. нужно открытый ключ с закрытым поменять местами.

Кстати, подпись в CMS-сообщении Microsoft сохраняет правильно (по стандарту), иначе их реализация CMS ни с кем бы навстречу не работала. Переворачивать-то они переворачивают, но лишь потому что на выходе из CryptSignHash() подпись перевёрнута. Почему это так - это отдельный вопрос, но к стандартам он не имеет отношения.

2Konstantin: Давайте пойдём от начала. В чём заключается задача и откуда возникла необходимость получить хэш-значение исходных данных? Что мешает его посчитать по этим данным?

Отредактировано пользователем 25 июня 2009 г. 13:27:39(UTC)  | Причина: Не указана

Последний стандарт на CMS - это RFC3852. Раздел 5.5 говорит о том, что подпись надо представить в виде OCTET STRING, а за подробностями отсылает к описаниям конкретных алгоритмов. Теперь смотрим RFC3370 под названием "Cryptographic Message Syntax (CMS) Algorithms", находим, например, раздел про RSA (3.2), и делаем вывод, что OCTET STRING с выхода RSA надо без каких-либо преобразований поместить как значение подписи в CMS.

Именно так CryptoAPI и делает. Можете проверить это буквально, посчитав подпись RSA с помощью вашей любимой криптографической библиотеки (ну или с помощью калькулятора ;). Можете по-другому - подпишите письмо сертификатом RSA в Outlook/Outlook Express и проверьте подпись, например, в The Bat! без помощи CryptoAPI - всё будет прекрасно работать.

Посмотрел еще информацию по CryptVerifySignature: похоже это проблемы native CryptoAPI с использованием "little-endian" формата. И "исправилась" Microsoft только в .NET Framework:

If you generate a signature by using the .NET Framework APIs and try to verify it by using the CryptVerifySignature function, the function will fail and GetLastError will return NTE_BAD_SIGNATURE. This is due to the different byte orders between the native Win32 API and the .NET Framework API.

The native cryptography API uses little-endian byte order while the .NET Framework API uses big-endian byte order. If you are verifying a signature generated by using a .NET Framework API, you must swap the order of signature bytes before calling the CryptVerifySignature function to verify the signature.

Таким образом я соглашаюсь, что Microsoft формирует конечную подпись в PKCS сообщениях правильно если используются высокоуровневые функции. При использовании же низкоуровневых функций типа CryptMsgEncode необходимо переворачивать выход CryptSignHash перед сохранением его в ASN.1 структурах.

Да уж, не утешительно.


Этот хэш нужен в двух задачах:
1. Для представления подписи в формате XMLDSIG и/или XADES.
2. Формируем хэш на Сервере, отправляем его Клиенту, подписываем на Клиенте, отправляем подпись на Сервер, Сервер извлекает хэш из подписи и сверяет тот ли хэш был подписан.

Повторно посчитать хэш мешает то, что данные гигабайтные и их много.