Статус: Участник
Группы: Участники
Зарегистрирован: 19.09.2013(UTC) Сообщений: 18
|
Дальнейшее изучение проблемы выявило следующие детали: 1) через поток, похоже, отдаются неверные размеры данных, отличающиеся в зависимости от велечины заданной в CMSG_STREAM_INFO::cbContent. Это видно если сравнить начальные байты заголовков полученных файлов. 2) эта же проблема наблюдается при попытке создания attached-подписи через CryptMsgOpenToEncode, но, как и при шифровании, при получении контента через ::CryptMsgGetParam(hMsg, CMSG_CONTENT_PARAM,...) все ОК. 3) если указать CMSG_STREAM_INFO::cbContent достаточно большим (например 1024) данные становятся не валидными в смысле ASN1. 4) если указать CMSG_STREAM_INFO::cbContent сравнительно малым (например 512 и меньше, но больше 0) данные будут валидны по ASN1, но не поддаются расшифровке с сообщением "Набор ключей не определен. (0x80090019)" 5) если указать CMSG_STREAM_INFO::cbContent равным -1 появляются нюансы. 5.1) операции с маленьким файлом (1092 байта) проходят успешно! Те файл расшифровывается как с помощью CryptMsgOpenToEncode, так и через поток CryptMsgOpenToDecode. 5.2) файл размером 6129889 байт успешно расшифровывается через поток CryptMsgOpenToDecode, но при вызове CryptMsgOpenToEncode возникает ошибка "Нехватка памяти для ASN1. (0x80093106)".
Пологаю, что факт успешной расшифровки в обозначенных выше случаях снимает вопрос корректности кода-обвязки, и показывает возможные проблемы в использовани CAPI или в нем самом.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 675   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз Поблагодарили: 95 раз в 68 постах
|
Автор: burning-dragon  Дальнейшее изучение проблемы выявило следующие детали: 1) через поток, похоже, отдаются неверные размеры данных, отличающиеся в зависимости от велечины заданной в CMSG_STREAM_INFO::cbContent. Это видно если сравнить начальные байты заголовков полученных файлов. 2) эта же проблема наблюдается при попытке создания attached-подписи через CryptMsgOpenToEncode, но, как и при шифровании, при получении контента через ::CryptMsgGetParam(hMsg, CMSG_CONTENT_PARAM,...) все ОК. 3) если указать CMSG_STREAM_INFO::cbContent достаточно большим (например 1024) данные становятся не валидными в смысле ASN1. 4) если указать CMSG_STREAM_INFO::cbContent сравнительно малым (например 512 и меньше, но больше 0) данные будут валидны по ASN1, но не поддаются расшифровке с сообщением "Набор ключей не определен. (0x80090019)" 5) если указать CMSG_STREAM_INFO::cbContent равным -1 появляются нюансы. 5.1) операции с маленьким файлом (1092 байта) проходят успешно! Те файл расшифровывается как с помощью CryptMsgOpenToEncode, так и через поток CryptMsgOpenToDecode. 5.2) файл размером 6129889 байт успешно расшифровывается через поток CryptMsgOpenToDecode, но при вызове CryptMsgOpenToEncode возникает ошибка "Нехватка памяти для ASN1. (0x80093106)".
Пологаю, что факт успешной расшифровки в обозначенных выше случаях снимает вопрос корректности кода-обвязки, и показывает возможные проблемы в использовани CAPI или в нем самом. Переписать то код пробывали во что-то по проще? |
С уважением, Юрий Строжевский |
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.09.2013(UTC) Сообщений: 18
|
Цитата:Переписать то код пробывали во что-то по проще? Куда уж проще...? Для успокоения совести отключал smartpointer-ы. Кстати, при использовании алгоритма шифрования RSA_RC4 этот код работает вполне себе корректно. Так что проблема судя по всему не в "сложности" кода.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 675   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз Поблагодарили: 95 раз в 68 постах
|
Автор: burning-dragon  Цитата:Переписать то код пробывали во что-то по проще? Куда уж проще...? Для успокоения совести отключал smartpointer-ы. Кстати, при использовании алгоритма шифрования RSA_RC4 этот код работает вполне себе корректно. Так что проблема судя по всему не в "сложности" кода. На нескольких разных сертификатах (ГОСТ'овых) пробывали или только на одном? |
С уважением, Юрий Строжевский |
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.09.2013(UTC) Сообщений: 18
|
на 2х разных, на всякий случай ключи в разных хранилищах
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 14,190   Сказал «Спасибо»: 621 раз Поблагодарили: 2397 раз в 1886 постах
|
Присланные в ЛС файлы: SOD_Toxicity.mp3_ber.dat - зашифрован в BER (CMSG_STREAM_INFO::cbData = -1) - расшифровал. 5 248 395 байт
SOD_Toxicity.mp3_sem.dat - зашифрован в DER через CryptEncryptMessage - расшифровал. 5 248 395 байт
SOD_Toxicity.mp3_fsz.dat - зашифрован в DER (CMSG_STREAM_INFO::cbData = размер исходного фаайла) - Код ошибки: 2148077585 - Для завершения расшифровки потокового криптографического сообщения требуются дополнительные данные
SOD_Toxicity.mp3_512.dat - зашифрован в DER (CMSG_STREAM_INFO::cbData = 512) - Код ошибки: 2148077569 - Ошибка при обработке криптографического сообщения |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,457  Откуда: КРИПТО-ПРО Сказал «Спасибо»: 39 раз Поблагодарили: 750 раз в 645 постах
|
Цитата:cbContent Specifies the size, in bytes, of the content. Normal Distinguished Encoding Rules (DER) encoding is used unless CMSG_INDEFINITE_LENGTH (0xFFFFFFFF) is passed, indicating that the application is not specifying the content length. This forces the use of indefinite-length Basic Encoding Rules (BER) encoding. Зачем туда класть, что-то иное? |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 12.12.2007(UTC) Сообщений: 6,457  Откуда: КРИПТО-ПРО Сказал «Спасибо»: 39 раз Поблагодарили: 750 раз в 645 постах
|
Наконец-то понял, в чем проблема - нужно поточно кодировать в DER. Длина в нынешней реализации считается с запасом, иначе бы пришлось проводить затратные криптоперации. В будущем возможно сделаем Strict режим. Поточный режим все-таки принято использовать для BER. Отредактировано пользователем 26 сентября 2013 г. 10:20:10(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.09.2013(UTC) Сообщений: 18
|
Таким образом получается: 1) При потоковом кодировании по ГОСТу при использовании BER-кодировки все работает корректно. 2) При потоковом кодировании по ГОСТу при использовании DER-кодировки в исходящий поток возвращаются не корректные данные. Таким образом обеспечить совместимость поточного кодирования и цельного-блочного (CryptEncryptMessage) не представляется возможным. А это является большой проблемой.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 22.01.2008(UTC) Сообщений: 675   Откуда: Йошкар-Ола Сказал «Спасибо»: 3 раз Поблагодарили: 95 раз в 68 постах
|
Автор: burning-dragon  Таким образом получается: 1) При потоковом кодировании по ГОСТу при использовании BER-кодировки все работает корректно. 2) При потоковом кодировании по ГОСТу при использовании DER-кодировки в исходящий поток возвращаются не корректные данные. Таким образом обеспечить совместимость поточного кодирования и цельного-блочного (CryptEncryptMessage) не представляется возможным. А это является большой проблемой.
Дык сказали же несколько раз: у всех все работает. Например в КриптоАрме потоковое кодирование работает уже 10 лет. Проблема только в вашем коде. |
С уважением, Юрий Строжевский |
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close