Причем тут CryptEncryptMessage? Код приведен для работы с другой функции.

На самом деле это утверждение ложно. В конце представленного сообщения записан "мусор".
Предупреждение от dumpasn1: Warning: Further data follows ASN.1 data at position 2958.

Поэтому и ошибки с CryptDecryptMessage.

В общем ищите что там у вас делается с записью в поток, особенно на завершающем этапе.

Если есть сомнения то посчитайте "руками": вот первые четыре байта из проверяемого файла

По этим байтам можно видеть, что верхняя объемлющая структура имеет тип SEQUENCE и длину в 2954 байт. Добавляя эти первые 4 байта получаем, что весь файл должен быть не длиннее 2958 байт, что совпадает с данными dumpasn1.
Длина же проверяемого файла составляет 3041 байт, что позволяет утверждать, что в конце записан "мусор".

Отредактировано пользователем 21 сентября 2013 г. 7:12:36(UTC)  | Причина: Не указана

Собственно дело не в том, что в поточно-созданном сообщении всегда есть мусор. Наоборот - обычно его там нет.
Мой вариант работы с сообщениями, созданными с использованием "потоков" был успешно создан и работает в КриптоАрм уже 10 лет (кстати в октябре-ноябре КриптоАрму будет ровно 10 лет! Та-дам!).

Поймите что очень у многих людей до вас получалось использовать потоковые функции. И результат этих функций потом упешно читался функцией CryptDecryptMessage.

С кодом, относящимся к CryptoAPI, вроде все нормально, но тем не менее "мусор" в вашем выходном сообщении есть.

Так что просто ищите что же ошибочно в коде, не относящемся к CryptoAPI. Поменяйте цикл чтения из потока, перепишите все без использования "умных" объектов.
Возможно что-то у себя и найдёте. То есть ещё раз - скорее всего ошибка где-то в вашей программе в части не относящейся к CryptoAPI. Экспериментируйте.