Вопрос был как раз как проверять "сырую" подпись полученную из плагина на сервере с Linux публичным ключом.
Спасибо за пояснение о другом формате подписи из плагина, команда преобразования подписи помогла

cat test.sign | tr -d : | xxd -r -p > test.sign_pure

Подпись успешно проверяется через openssl на сервере. Еще раз спасибо!

У вас хеш и подпись перемешались.
Команда:

openssl dgst -engine gost -md_gost12_256 test.txt

это команда получения хеша от текста.

Чтобы вычислить подпись, нужно выполнить:

openssl
Openssl>engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/engines-1.1/librtengine.so  -pre ID:rtengine -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:librtpkcs11ecp.so
Openssl>dgst -engine rtengine -keyform engine -md_gost12_256 -sign "pkcs11:id=%46%42%15%c9%49%b1%6a%09%71%f9%43%1b%2a%51%35%6b%4f%80%6e%11" -out test.sign test.text

%46%42%15%c9%49%b1%6a%09%71%f9%43%1b%2a%51%35%6b%4f%80%6e%11 -- идентификатор ключа на токене, у вас он будет отличаться. В качестве разделителей используется %.

test.text -- файл, для которого считается подпись
test.sign -- файл, куда запишется результат подписи

Результат будет храниться в бинарном формате (не текстовом в hex).

На странице https://aktivco.github.io/rutoken-plugin-demo/ получается подпись, разделенная двоеточиями и в шестнадцатеричном формате. Для этого сначала подсчитайте хеш (операция "Вычислить хеш"), от текста. Полученный хеш скопируйте на вкладку "Подпись на ключе". Выход и будет подписью.

OpenSSL работает с другим форматом подписи. Чтобы конвертировать подпись полученную из Плагина выполните

cat test.sign | tr -d : | xxd -r -p > test.sign_pure

Дальше уже можно выполнить проверку подписи:

 
openssl dgst -engine gost -md_gost12_256 -verify pubkey.pem -signature test.sign_pure  test.text

Если вы получили подпись с помощью openssl, то шаг конвертации можно пропустить.

Напомню, что подсчет подписи по ГОСТ состоит из двух этапов. Подсчет хеша, затем непосредственно подпись от полученного значения. Именно поэтому при работе через сайт мы выполняем два действия.

pubclear.pem - это экспортированный публичный ключ из сертификата.
test.sgn - подпись по ключу из демо-страницы РуТокен (https://aktivco.github.io/rutoken-plugin-demo/)
test.txt - файл с подписанными данными

При этом хэш сделанный на демо-странице совпадает с хешем, который снимаю через openssl.
openssl dgst -engine gost -md_gost12_256 test.txt
engine "gost" set.
md_gost12_256(test.txt)= 5bcf7369336eb76fe916f83974cdc21ac677b5af8e25061495395c257ecdecb0

На демо-странице:
Хеш (размер должен соответствовать алгоритму хеширования): 5b:cf:73:69:33:6e:b7:6f:e9:16:f8:39:74:cd:c2:1a:c6:77:b5:af:8e:25:06:14:95:39:5c:25:7e:cd:ec:b0

Единственное отличие - это наличие двоеточий, через каждые 2 символа.

Пробовал полученную подпись на ключе ("сырую") писать в test.sgn как с двоеточием, так и без, но все равно Verification Failure.

Wildtuna, добрый день!

Через cryptcp нельзя ни создать, ни проверить "сырую" подпись. Только в CMS-конверте.

А не подскажете через какой инструмент можно проверить "сырую" подпись?

Через cryptcp нельзя ни создать, ни проверить "сырую" подпись. Только в CMS-конверте.

Wildtuna, добрый вечер!

У нас процесс построен так:
1. На токене создаем ключевую пару;
2. Формируем запрос на сертификат в УЦ и издаем сертификат;
3. Не записывая сертификат на токен формируем подпись данных и проверяем сертификатом на сервере.

Видимо, возникает какое-то недопонимание по причине недосказанности и различий в предположениях об области применения. Заранее прошу прошения, если написанное ниже окажется очевидным и не требующим уточнения -- оно написано только для того, чтобы убедиться, что мы находимся в одинаковой системе координат.

В инфраструктуре PKI, а в нее мы попадаем, если начинаем говорить о сертификатах X.509, под электронной подписью обычно понимают подпись в формате CMS. Для формирования данной структуры требуется указание сертификата (как минимум, для заполнения структуры SignerInfo).

Если вы говорите о том же формате, то согласитесь, что для подписи необходима передача сертификата в интерфейс функции подписи. Кроме того, данный формат допукает включение в подписанное сообщение произвольного набора сертификатов, включая сертификат подписанта, так что пропадает необходимость хранить его централизованно у получателя -- сервера, в вашем случае.

В случае если вы все-таки подразумеваете так называемую "сырую" электронную подпись, не предполагающую формирование специальных структур сообщений, можете воспользоваться функцией rawSign. Документацию, включающую описание этой функции можно найти на портале документации. Проверить работу этой и других функций можно на демо-площадке.

Евгений, большое спасибо за такой развернутый ответ!
Да, в данном случае интересует именно "Сырая" подпись. Спасибо, нашел раздел "Подпись на ключе" на вашем демо-сайте.

Подскажите, а как потом эту подпись проверить через вашу утилиту на Linux cryptcp при условии, что сертификаты не установлены в хранилище? Как я понял из сообщений на форуме у команды -vsignf  есть ключ -f, который позволяет указать путь до сертификата. использовать эту команду для проверки такой подписи, при условии, что в cert.cer цепочка серитфикатов из пользовательского сертификата и сертификата УЦ?

Видимо, возникает какое-то недопонимание по причине недосказанности и различий в предположениях об области применения. Заранее прошу прошения, если написанное ниже окажется очевидным и не требующим уточнения -- оно написано только для того, чтобы убедиться, что мы находимся в одинаковой системе координат.

В инфраструктуре PKI, а в нее мы попадаем, если начинаем говорить о сертификатах X.509, под электронной подписью обычно понимают подпись в формате CMS. Для формирования данной структуры требуется указание сертификата (как минимум, для заполнения структуры SignerInfo).

Если вы говорите о том же формате, то согласитесь, что для подписи необходима передача сертификата в интерфейс функции подписи. Кроме того, данный формат допукает включение в подписанное сообщение произвольного набора сертификатов, включая сертификат подписанта, так что пропадает необходимость хранить его централизованно у получателя -- сервера, в вашем случае.

В случае если вы все-таки подразумеваете так называемую "сырую" электронную подпись, не предполагающую формирование специальных структур сообщений, можете воспользоваться функцией rawSign. Документацию, включающую описание этой функции можно найти на портале документации. Проверить работу этой и других функций можно на демо-площадке.

Wildtuna пишет:

Добрый день, если на токене есть ключевая пара, а сертификат только на сервере. Как можно подписать данные приватным ключом с токена без помещения сертификата в токен?

Добрый день!

Если кратко, то никак нельзя подписать данные без сертификата через плагин.
А в чем проблема поместить сертификат на токен?

У нас процесс построен так:
1. На токене создаем ключевую пару;
2. Формируем запрос на сертификат в УЦ и издаем сертификат;
3. Не записывая сертификат на токен формируем подпись данных и проверяем сертификатом на сервере.

С Рутокен схема не работает, так как не дает этого сделать без сертификата. А зачем ему сертификат для подписи, если для этого нужен только приватный ключ?

Добрый день, если на токене есть ключевая пара, а сертификат только на сервере. Как можно подписать данные приватным ключом с токена без помещения сертификата в токен?

Добрый день!

Если кратко, то никак нельзя подписать данные без сертификата через плагин.
А в чем проблема поместить сертификат на токен?