Статус: Участник
Группы: Участники
Зарегистрирован: 26.02.2013(UTC) Сообщений: 15  Откуда: Россия Сказал(а) «Спасибо»: 1 раз
|
Сверил обе подписи в редакторе ASN.1, разница только в смещении: Подпись АРМ: Код:
0 NDEF: SEQUENCE {
2 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
: (PKCS #7)
13 NDEF: [0] {
15 NDEF: SEQUENCE {
17 1: INTEGER 1
20 12: SET {
22 10: SEQUENCE {
24 6: OBJECT IDENTIFIER gostDigest (1 2 643 2 2 9)
: (GOST R 34.11-94 digest)
32 0: NULL
: }
Подпись CSP (моя подпись): Код:
0 2632: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
: (PKCS #7)
15 2617: [0] {
19 2613: SEQUENCE {
23 1: INTEGER 1
26 12: SET {
28 10: SEQUENCE {
30 6: OBJECT IDENTIFIER gostDigest (1 2 643 2 2 9)
: (GOST R 34.11-94 digest)
38 0: NULL
: }
Есть предположения, из за чего такое происходит? Если нужно, могу приложить обе подписи.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 25.12.2007(UTC) Сообщений: 1,733  Откуда: КРИПТО-ПРО Поблагодарили: 177 раз в 168 постах
|
Цитата:Есть предположения, из за чего такое происходит? Если нужно, могу приложить обе подписи. Извините, в первую очередь Вам нужно ознакомиться с этим фундаментальным трудом.А пока что уберите "+1" из вычисления значения cbMessage. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.02.2013(UTC) Сообщений: 15 Откуда: Россия Сказал(а) «Спасибо»: 1 раз
|
Автор: Kirill Sobolev  Извините, в первую очередь Вам нужно ознакомиться с этим фундаментальным трудом.А пока что уберите "+1" из вычисления значения cbMessage. Извините, я конечно понимаю, что мои знания Си далеки от идеальных, однако во всех примерах, которые я нашел, есть +1, и в частности http://msdn.microsoft.co...p/aa382372(v=vs.85).aspx написано: Цитата:// Calculate the size of message. To include the
// terminating null character, the length is one more byte
// than the length returned by the strlen function.
cbMessage = (lstrlen((TCHAR*) pbMessage) + 1) * sizeof(TCHAR); Убрал "+1" из вычисления значения cbMessage, не помогло. Еще раз внимательно посмотрел подписи (АРМ и мою) - они различаются содержанием (OCTET STRING) блока: Код:
2267 47: SEQUENCE {
2269 9: OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
: (PKCS #9)
2280 34: SET {
2282 32: OCTET STRING
: 01 1A 27 1E DC 11 77 15 BD 12 CB 8D B8 39 29 07
: 9D 99 F8 37 9D EA 18 CE 7C 29 B0 A8 40 94 B9 80
: }
: }
Отредактировано пользователем 18 апреля 2013 г. 11:41:23(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 25.12.2007(UTC) Сообщений: 1,733 Откуда: КРИПТО-ПРО Поблагодарили: 177 раз в 168 постах
|
Цитата:во всех примерах, которые я нашел, есть +1 в примерах подписывается и проверяется текстовая строка, у Вас же на вход подается файл, в котором нет никакого Цитата:terminating null character Цитата:Убрал "+1" из вычисления значения cbMessage, не помогло. Выложите присоединенную подпись, которую Вы создаете. Цитата:Еще раз внимательно посмотрел подписи (АРМ и мою) - они различаются содержанием (OCTET STRING) блока Так и должно быть |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.02.2013(UTC) Сообщений: 15 Откуда: Россия Сказал(а) «Спасибо»: 1 раз
|
Автор: Kirill Sobolev Выложите присоединенную подпись, которую Вы создаете. Выкладываю отсоединенную и присоединенную подписи: http://rghost.ru/downloa...2ec53439ac3c2db9/req.rarПароль: sig В коде убрал "+1". UP. Прикол в том, что присоединенную подпись АРМ корректно проверяет. А на отсоединенной выдает ошибку. Правда при проверке после отсоединения подписи исходный файл, созданный АРМ, имеет в конце файла лишние символы. Отредактировано пользователем 18 апреля 2013 г. 14:32:13(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 25.12.2007(UTC) Сообщений: 1,733 Откуда: КРИПТО-ПРО Поблагодарили: 177 раз в 168 постах
|
В аттаче тот буфер, который Вы реально передаете на подпись - конец у него выглядит ну очень криво. Но отсоединенная подпись с ним проверяется нормально.
C:\Temp\apofig>csptest -sfsign -verify -detached -in req-bad.xml -signature req.detached.xml.sig
An error occurred in running the program.
.\signtsf.c:607:No user cert specified. Cryptocontext will be opened automaticaly.
Error number 0x0 (0).
Операция успешно завершена.
Detached Signature was verified OK
Total: SYS: 0,016 sec USR: 0,016 sec UTC: 0,078 sec
[ErrorCode: 0x00000000]
Код чтения, кстати, можно немного упростить Код:std::ifstream fl("D:\\req.xml", std::ios::ate | std::ios::binary);
size_t len = fl.tellg();
char *ret = new char[len];
fl.seekg(0, std::ios::beg);
fl.read(ret, len);
fl.close();
BYTE* pbMessage = (BYTE*)ret;
DWORD cbMessage = len;
Отредактировано пользователем 18 апреля 2013 г. 14:54:10(UTC)
| Причина: Не указана Вложение(я):  req-bad.xml (3kb) загружен 3 раз(а).У Вас нет прав для просмотра или загрузки вложений. Попробуйте зарегистрироваться. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.02.2013(UTC) Сообщений: 15 Откуда: Россия Сказал(а) «Спасибо»: 1 раз
|
Автор: Kirill Sobolev В аттаче тот буфер, который Вы реально передаете на подпись - конец у него выглядит ну очень криво. Именно так. Странно, что в КриптоАРМ, если создать присоединенную подпись этого файла, и потом проверить с отсоединением, то на выходе файл один в один с исходным, без всяких лишних символов.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 25.12.2007(UTC) Сообщений: 1,733 Откуда: КРИПТО-ПРО Поблагодарили: 177 раз в 168 постах
|
Т.е. в исходном req.xml последние 80 байт из 2678 тоже мусор? |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 26.02.2013(UTC) Сообщений: 15 Откуда: Россия Сказал(а) «Спасибо»: 1 раз
|
Автор: Kirill Sobolev Т.е. в исходном req.xml последние 80 байт из 2678 тоже мусор? Нет, я имел ввиду, что я тоже заметил, что после отсоединения файла от подписи, в нем оказался мусор. Прикладываю исходный файл: http://rghost.ru/downloa...fdba38762a8f7ebb/req.rarПароль: sig Т.е. получается, что на подпись подается уже искаженный файл и поэтому КриптоАРМ при проверке выдает ошибку? А мой код соответственно проверяет на основе этого искаженного файла, поэтому ошибки не выдает. Отредактировано пользователем 18 апреля 2013 г. 16:23:22(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 25.12.2007(UTC) Сообщений: 1,733 Откуда: КРИПТО-ПРО Поблагодарили: 177 раз в 168 постах
|
Цитата:Т.е. получается, что на подпись подается уже искаженный файл и поэтому КриптоАРМ при проверке выдает ошибку? А мой код соответственно проверяет на основе этого искаженного файла, поэтому ошибки не выдает. Совершенно верно. Чтобы разобраться в ситуации попробуйте для начала выкинуть всю криптографию и проверить только чтение и запись. |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
