14.11.2004 11:38:14Определение типа подписи Ответов: 32
Nekra
Имеется файл с подписью *.p7s
Как определить является ли подпись detached или нет, используя CryptoAPI ?
 
Ответы:
15.11.2004 10:37:29Kirll Sobolev
Это абстрактный интерес или реальная проблема, требующая решения?
15.11.2004 12:47:01Александр
Здравствуйте!
Я тоже пытался решить эту проблему, и даже задавал вопрос, но вразумительного ответа не получил. Поэтому присоединяюсь к вопосу.
???
15.11.2004 12:49:59Kirill Sobolev
А у Вас что за задача, что требуется определение attached/detached через CryptoAPI?
15.11.2004 13:25:52Александр
требуется программно определить по файлу p7s, отдельная это подпись или с данными.
15.11.2004 13:34:07Kirill Sobolev
Если есть только файл p7s, то рассматривать его как detached смысла не имеет.
15.11.2004 13:49:55Александр
Мне нужно проверить подпись. Если там есть данные то всё прекрасно, а если там их нет, то всё рухнет. И вот мне нужно до начала проверки подписи (т.е. функции CryptMsgOpenToDecode() нужно указать отдельная это подпись или нет) это выяснить.
15.11.2004 14:20:47Kirill Sobolev
Ничего не падает, CryptMsgUpdate и CryptMsgControl отрабатывают вполне корректно.
15.11.2004 14:35:20Александр
Не точно выразился. Они (функции) скажут что подпись верна, хотя неизвестно что произошло с файлом.
Задача состоит в следующем:
нужно проверить подпись файла;
если подись отдельная то выкинуть окно с указанием файла к которому эта подпись относится;
далее считаем хэш этого документа ну а уж потом проверяем подпись.
15.11.2004 14:42:23Kirill Sobolev
Если они скажут что подпись верна - значит подпись не detached, все нормально и больше ничего делать не надо. Если вернут ошибку - значит или подпись неверна, или еще что-нибудь (мб и отсутствие данных).
15.11.2004 15:02:56nekra
Необходимо сделать как в КриптоАРМ - вы выборе отсоениненной подписи он спрашивает исходный файл, если же подпись и файл идут в одном файле то он ничего дополнительного не просит. Значит он нормально определяет тип подписи. Мне необходимо сделать тоже самое.
15.11.2004 15:04:33Александр
это как минимум двухпроходная схема.
ошибки, связанной с отсутствием данных в подписанном сообщении, я не нашёл, т.е. нельзя определить есть там данные или нет.
15.11.2004 17:29:03Kirill Sobolev
Как в КриптоАРМ сделано я не знаю :)
И как в один проход тоже...
Но можно сделать CryptMsgOpenToDecode без CMSG_DETACHED_FLAG, потом спросить CryptMsgGetParam(CMSG_CONTENT_PARAM, NULL, &cbSize). Если данные были detached то cbSize будеь нулем, иначе там будет размер подписанных данных.
15.11.2004 17:53:35Александр
А чем отличается поведение функции CryptMsgOpenToDecode() при установленном флаге CMSG_DETACHED_FLAG и без него?
15.11.2004 20:02:35nekra
Спасибо.
CryptMsgOpenToDecode без CMSG_DETACHED_FLAG и CryptMsgGetParam(CMSG_CONTENT_PARAM, NULL, &cbSize) как раз то что нужно оказалось.
16.11.2004 9:56:54Kirill Sobolev
2Александр : тем что при установленном флаге проверятся detached подпись. Т.е. отдельно можно засунуть данные, отдельно pkcs7.
2Nekra : пожалуйста, но это все равно то что Александр назвал 2 прохода...
16.11.2004 10:31:57Александр
Спасибо за ответы.
Скажите пожалуйста как туда можно запихнуль простые данные?
16.11.2004 10:32:09Александр
Спасибо за ответы.
Скажите пожалуйста как туда можно запихнуль простые данные?
16.11.2004 10:44:29Kirill Sobolev
Посмотрите наш csptest, файл signlo.c функция do_low_verify.
18.11.2004 12:55:33Юрий
Я знаю, как сделано в КриптоАРМ (я его написал :)))

Метод действительно ДВУХпроходный: то есть сначала из файла пытаются извлечь блок данных стандартными способами (MsgToDecode & MsgUpdate)-если получается извлечь данные, то они там есть (attached)-если нет, то detached.
Правда, одна загвоздка: там используется работа с последним параметом функции CryptMsgOpenToDecode - описателем потока, работа с которым почти ни где не описана. Советую внимательно прочитать описание этого последнего параметра.
Если чего - пишите :)
18.11.2004 12:56:32Юрий
Я знаю, как сделано в КриптоАРМ (я его написал :)))

Метод действительно ДВУХпроходный: то есть сначала из файла пытаются извлечь блок данных стандартными способами (MsgToDecode & MsgUpdate)-если получается извлечь данные, то они там есть (attached)-если нет, то detached.
Правда, одна загвоздка: там используется работа с последним параметом функции CryptMsgOpenToDecode - описателем потока, работа с которым почти ни где не описана. Советую внимательно прочитать описание этого последнего параметра.
Если чего - пишите :)
18.11.2004 12:56:50Юрий
Я знаю, как сделано в КриптоАРМ (я его написал :)))

Метод действительно ДВУХпроходный: то есть сначала из файла пытаются извлечь блок данных стандартными способами (MsgToDecode & MsgUpdate)-если получается извлечь данные, то они там есть (attached)-если нет, то detached.
Правда, одна загвоздка: там используется работа с последним параметом функции CryptMsgOpenToDecode - описателем потока, работа с которым почти ни где не описана. Советую внимательно прочитать описание этого последнего параметра.
Если чего - пишите :)
18.11.2004 13:00:12Юрий
Извините за много однотипных ответов - сервер что-то глючил, выдавал ошибку...
18.11.2004 13:51:41александр
Добрый день!
Да загвоздка действительно есть.
Если в CryptMsgOpenToDecode() указывать последний параметр, то после обработки сообщения не удаётся вызвать CryptMsgGetParam(...CMSG_CONTENT_PARAM...): вылазит ошибка что параметр задан неверно.
А если не указывать этот параметр, то функция CryptMsgGetParam(...CMSG_CONTENT_PARAM...) в любом случае говорит что данные есть.
Как быть?

И ещё я задавал несколько схожий вопрос
(http://www.cryptopro.ru/CryptoPro/forum/myforum.asp?q=1337).
Может быть вы мне подскажите что-нибудь?

Буду благодарен за любую помощь!
18.11.2004 14:22:13Юрий
Ну я же говорил: "...посмотрите внимательно на описание последнего параметра...". Дело в том, что в случае присоединенной подписи поток, описанный последним параметром функция CryptMsgUpdate выводит САМИ ПРИСОЕДИНЕННЫЕ ДАННЫЕ. То есть достаточно прочитать MsgUpdate хоть 2 байта - мы тут же узнаем, есть ли данные или нет.
CryptMsgControl же возвращает инкапсулированный контекст только в память.
18.11.2004 14:58:26александр
А что бы узнать есть ли данные нужно проверять параметр CallBack функции?
18.11.2004 15:01:04Юрий
...Ну а если проблема только в том, чтобы извлечь из файла с подписью огромного размера данные, то это только с помощью это параметра MsgToDecode - описателя потока...
18.11.2004 15:05:18Юрий
Про CallBack-функцию: меня не поняли. В эту функцию в качестве параметров при каждом вызове функции CryptMsgUpdate возвращаеется по кусочкам ВЕСЬ контекст, присоединенных к подписи данных. Хотя...ну да, нужно проверять параметр callback-функции :))
18.11.2004 15:42:06александр
А может быть можно как-то ещё? т.е CryptMsgUpdate() отработала полностью и после этого мы имеем сообщение. вот по нему можно определить были ли там данные или нет?
18.11.2004 16:12:52Юрий
Еще раз... У функции CryptMsgOpenToDecode есть последний параметр - описатель потока. При использовании этой функции для декодирования подписи, содержащей данные, в качестве парамета для callback-функции передается часть присоединенных данных. То есть УЖЕ ПО ПЕРВОМУ вызову функции CryptMsgUpdate можно узнать, есть ли в файле подписи данные или же их там нет.

Все понятно?
18.11.2004 16:38:08александр
Ещё раз... Мне всё с этим ясно.
ПОСЛЕ ОБРАБОТКИ МОЖНО УЗНАТЬ ИЛИ НЕТ?
Изменяет ли функция CryptMsgUpdate()
параметры структуры CMSG_STREAM_INFO, в частности поле cbContent?
18.11.2004 16:50:22Юрий
А при чем здесь CMSG_STREAM_INFO???
Внутренние (упакованные вместе с подписью данные) передаются в ПАРАМЕТРАХ к функции, заданной в качестве pfnStreamOutput. А параметр cbContent для корректной работы всегда ставят в 0xFFFFFFFF, он роли не играет.
18.11.2004 16:54:06александр
Спасибо Большое!
не буду вас больше мучать :)