Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15  Сказал(а) «Спасибо»: 1 раз
|
Формирую pkc7-подпись к email-сообщению с использованием cryptcp (c ключем -detached). Код отрабатывается и на Win, и на Deb. Версия и там и там 5.0.12000 КС1. На обоих платформах проверка подписи средствами КриптПро даёт положительный результат.
Однако, если отправлять письмо с Win - почта видит письмо с валидной подписью. А если с Deb - пишет что содержимое письма было изменено. При этом код, формирующий тело письма, на обоих платформах один и тот же.
В связи с этим вопрос - cryptcp на обоих платформах ведёт себя одинаково или есть нюансы?
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15 Сказал(а) «Спасибо»: 1 раз
|
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,764  Сказал «Спасибо»: 579 раз
Поблагодарили: 2307 раз в 1807 постах
|
Автор: Uruzaner  Формирую pkc7-подпись к email-сообщению с использованием cryptcp (c ключем -detached). Код отрабатывается и на Win, и на Deb. Версия и там и там 5.0.12000 КС1. На обоих платформах проверка подписи средствами КриптПро даёт положительный результат.
Однако, если отправлять письмо с Win - почта видит письмо с валидной подписью. А если с Deb - пишет что содержимое письма было изменено. При этом код, формирующий тело письма, на обоих платформах один и тот же.
В связи с этим вопрос - cryptcp на обоих платформах ведёт себя одинаково или есть нюансы? Ведёт одинаково, можно же проверить подпись сделанную в Debian в ОС Windows. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15 Сказал(а) «Спасибо»: 1 раз
|
Автор: Андрей * Автор: Uruzaner Формирую pkc7-подпись к email-сообщению с использованием cryptcp (c ключем -detached). Код отрабатывается и на Win, и на Deb. Версия и там и там 5.0.12000 КС1. На обоих платформах проверка подписи средствами КриптПро даёт положительный результат.
Однако, если отправлять письмо с Win - почта видит письмо с валидной подписью. А если с Deb - пишет что содержимое письма было изменено. При этом код, формирующий тело письма, на обоих платформах один и тот же.
В связи с этим вопрос - cryptcp на обоих платформах ведёт себя одинаково или есть нюансы? Ведёт одинаково, можно же проверить подпись сделанную в Debian в ОС Windows. Тогда решительно непонятно, почему в итоге одну подпись Аутлук валидирует, а другую - нет. Даже на обычных тестовых данных в виде строчки "12345". Отредактировано пользователем 29 сентября 2023 г. 16:36:05(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,764 Сказал «Спасибо»: 579 раз
Поблагодарили: 2307 раз в 1807 постах
|
Автор: Uruzaner Автор: Андрей * Автор: Uruzaner Формирую pkc7-подпись к email-сообщению с использованием cryptcp (c ключем -detached). Код отрабатывается и на Win, и на Deb. Версия и там и там 5.0.12000 КС1. На обоих платформах проверка подписи средствами КриптПро даёт положительный результат.
Однако, если отправлять письмо с Win - почта видит письмо с валидной подписью. А если с Deb - пишет что содержимое письма было изменено. При этом код, формирующий тело письма, на обоих платформах один и тот же.
В связи с этим вопрос - cryptcp на обоих платформах ведёт себя одинаково или есть нюансы? Ведёт одинаково, можно же проверить подпись сделанную в Debian в ОС Windows. Тогда решительно непонятно, почему в итоге одну подпись Аутлук валидирует, а другую - нет. Даже на обычных тестовых данных в виде строчки "12345". подпись проходит проверку разными средствами? cryptcp, csptools (Инструменты КриптоПРО) в Windows? Без примеров (подпишите один и тот же файл в 2х ОС и приложите в архиве) - проверяйте самостоятельно. И как отправляется письмо, там нет проблем? |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15 Сказал(а) «Спасибо»: 1 раз
|
Автор: Андрей *
подпись проходит проверку разными средствами?
cryptcp, csptools (Инструменты КриптоПРО) в Windows?
Без примеров (подпишите один и тот же файл в 2х ОС и приложите в архиве) - проверяйте самостоятельно.
И как отправляется письмо, там нет проблем?
 test_for_sign.zip (5kb) загружен 1 раз(а).Во вложении архив. Файл один и тот же, на винде подписывался нативно с диска, на дебиане с того же диска, подцепленного через самбу. А вот подписи получились разные. У дебиановской в конце есть знак равно, а у виндовой - нет, что странно при одинаковом исходном файле. Я подумал мало ли, может особенности чтения в разных ФС, но перечитав посимвольно и сверив значение каждого символа по кодировочной таблице убедился, что после чтения файла строка получается идентичная. Отредактировано пользователем 29 сентября 2023 г. 22:16:43(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,764 Сказал «Спасибо»: 579 раз
Поблагодарили: 2307 раз в 1807 постах
|
подписан один и тот же файл (подписанные атрибуты: хеш = 8CA904F979574376B6DDFC6AFFCDF45C36BEB7EF43D6AA302264D4AB4CD47423) обе подписи проходят проверку в win\deb. Предлагаю: закодировать самостоятельно файлы в base64 (допустим? что "неправильное" кодирование), укажите опцию -der при подписании или в zip уже вложенные декодированные), в структурах asn.1 - разница в дополнительных 4х байтах на Windows: (смещение\asn.1) win: 20 $31 SETOF: ==>1 4 22 $30 SEQUENCE: ==>1 2 24 $06 OBJID: 1.2.643.7.1.1.2.2 34 $05 NULL: deb: 20 $31 SETOF: ==>1 2 22 $30 SEQUENCE: ==>1 0 24 $06 OBJID: 1.2.643.7.1.1.2.2 и далее: win:2393 $30 SEQUENCE: ==> 12 2395 $06 OBJID: 1.2.643.7.1.1.2.2 2405 $05 NULL: deb: 2391 $30 SEQUENCE: ==> 10 2393 $06 OBJID: 1.2.643.7.1.1.2.2 и всё. >>У дебиановской в конце есть знак равно, а у виндовой - нет это base64, особенности, файлы же имеют разный размер, но можете бинарные файлы сами закодировать и посмотреть разницу. test_for_sign (der).zip (4kb) загружен 1 раз(а).Отредактировано пользователем 29 сентября 2023 г. 23:44:30(UTC)
| Причина: Не указана |
|
 1 пользователь поблагодарил Андрей * за этот пост.
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15 Сказал(а) «Спасибо»: 1 раз
|
Автор: Андрей * подписан один и тот же файл (подписанные атрибуты: хеш = 8CA904F979574376B6DDFC6AFFCDF45C36BEB7EF43D6AA302264D4AB4CD47423) обе подписи проходят проверку в win\deb. Предлагаю: закодировать самостоятельно файлы в base64 (допустим? что "неправильное" кодирование), укажите опцию -der при подписании или в zip уже вложенные декодированные), в структурах asn.1 - разница в дополнительных 4х байтах на Windows: (смещение\asn.1) win: 20 $31 SETOF: ==>1 4 22 $30 SEQUENCE: ==>1 2 24 $06 OBJID: 1.2.643.7.1.1.2.2 34 $05 NULL: deb: 20 $31 SETOF: ==>1 2 22 $30 SEQUENCE: ==>1 0 24 $06 OBJID: 1.2.643.7.1.1.2.2 и далее: win:2393 $30 SEQUENCE: ==> 12 2395 $06 OBJID: 1.2.643.7.1.1.2.2 2405 $05 NULL: deb: 2391 $30 SEQUENCE: ==> 10 2393 $06 OBJID: 1.2.643.7.1.1.2.2 и всё. >>У дебиановской в конце есть знак равно, а у виндовой - нет это base64, особенности, файлы же имеют разный размер, но можете бинарные файлы сами закодировать и посмотреть разницу. test_for_sign (der).zip (4kb) загружен 1 раз(а). Всё оказалось до безобразного просто... В общем, RFC, который описывает MIME-контент в части pkcs7 жёстко привязан к Windows-ending в текстовых строках. В винде концовка строки это CRLF ('\r\n'), а в юниксе это LF ('\n'). Аутлук живёт в реалиях RFC и видимо приводит эндинги к формату самостоятельно, а не сверяет как есть. Но т.к. подпись идёт к строке с юникс-эндингом, то проверка и не бьётся. Дьявол, как обычно, прячется в деталях. Принудительно перед подписью и отправкой заменил эндинги с юникс на виндовые - и всё заработало. Проверил и просто с -detached, и с ручной перекодировкой из -der. Примечательно что с шифрованием таких плясок не нужно, голый -decr и всё прекрасно отработало. Спасибо за оперативную поддержку! Отредактировано пользователем 30 сентября 2023 г. 1:14:03(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,764 Сказал «Спасибо»: 579 раз
Поблагодарили: 2307 раз в 1807 постах
|
Автор: Uruzaner
Всё оказалось до безобразного просто...
В общем, RFC, который описывает MIME-контент в части pkcs7 жёстко привязан к Windows-ending в текстовых строках. В винде концовка строки это CRLF ('\r\n'), а в юниксе это LF ('\n'). Аутлук живёт в реалиях RFC и видимо приводит эндинги к формату самостоятельно, а не сверяет как есть. Но т.к. подпись идёт к строке с юникс-эндингом, то проверка и не бьётся. Дьявол, как обычно, прячется в деталях. Принудительно перед подписью и отправкой заменил эндинги с юникс на виндовые - и всё заработало. Проверил и просто с -detached, и с ручной перекодировкой из -der.
Примечательно что с шифрованием таких плясок не нужно, голый -decr и всё прекрасно отработало.
Спасибо за оперативную поддержку! а в примере (test_for_sign.txt) не было же... |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.01.2023(UTC) Сообщений: 15 Сказал(а) «Спасибо»: 1 раз
|
Автор: Андрей * Автор: Uruzaner
Всё оказалось до безобразного просто...
В общем, RFC, который описывает MIME-контент в части pkcs7 жёстко привязан к Windows-ending в текстовых строках. В винде концовка строки это CRLF ('\r\n'), а в юниксе это LF ('\n'). Аутлук живёт в реалиях RFC и видимо приводит эндинги к формату самостоятельно, а не сверяет как есть. Но т.к. подпись идёт к строке с юникс-эндингом, то проверка и не бьётся. Дьявол, как обычно, прячется в деталях. Принудительно перед подписью и отправкой заменил эндинги с юникс на виндовые - и всё заработало. Проверил и просто с -detached, и с ручной перекодировкой из -der.
Примечательно что с шифрованием таких плясок не нужно, голый -decr и всё прекрасно отработало.
Спасибо за оперативную поддержку! а в примере (test_for_sign.txt) не было же... Да, потому что когда я делал пример, то в эту сторону даже и не думал, просто подписал один и тот же файл. Но в боевых условиях на шару я не хожу, файл формируется локально и по правилам Unix. Такая вот история, надеюсь кому-то ещё будет полезной.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
