privkey fails to read containers created by CryptPro 5.0 about privkey HOT 30 OPEN

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

Тестирую на свежем криптопро 4.0 сертификате который недавно получил:

• Данная утилита "privkey" возвращает can not read container from D:\xxxxxxxx.000
• gostcrypto возвращает Container is not valid
• Утилита P12fromGostCSP возвращает ошибку (та бесплатная версия что я смог найти)
• нашёл также утилиту https://github.com/kov-serg/get-cpcert , последний коммит совсем недавно и вроде даже возвращает сертификат+ключ, но при попытке подписать реквест до ЕСИА получаю ошибку error_description = "ESIA-007005: The client is not authorized to request an access token using this method." Не могу разобраться в чём проблема пока что. С RSA всё работает

from privkey.

Добрый день! Только что увидел Ваш комментарий, извините!

1. 512 битовые ключи тоже тестировались и должны работать.

2. Насчёт смещений в asn1 это да, есть такое - что не парсится. Но структура эта достаточно загадочная, я думаю её специально сделали, чтоб вводить честных людей в заблуждение.)))

Короче, скорее всего выходом будет печатать primary.key header.key сначала в текстовый файл через какой-нибудь dumpasn1 а моя утилита далее парсит уже полученный текст. А если вдруг проблемы - всегда можно из текстового файла редактором выкинуть все непонятные поля. Основная проблема, как я понимаю, именно в том, что в 5.0 добавили новые поля? Если честно я версию 5.0 почти не смотрел. Эту версию уже сертифицировали?

from privkey.

Спасибо за ответ.

1. С тех пор как я написал свой вопрос много воды утекло :) Я написал свой парсер контейнеров КриптоПро с расшифровкой закрытых ключей обоих типов (exchange/signature). Да, в контейнере хранится 1 или 2 ключа. основная проблема с утилитой privkey в том, что полученный с помощью нее ключ неправильный, созданная с его помощью цифровая подпись не проверяется КриптоПро. Я эту проблему решил после долгих исследований.
2. Версию 5.0 насколько мне известно еще не сертифицировали.

from privkey.

основная проблема с утилитой privkey в том, что полученный с помощью нее ключ неправильный

Это какой ключ? Это 512-тибитный неправильный? Я когда проверял - вроде бы всё правильно во всех позах (см пункты 6 и 7 в readme.md) , надо только не забывать "переворачивать" ключ, в OpenSSL он лежит старшими битами вперёд, то есть наоборот чем в Крипто-Про.

Хотя стоп! Вспомнил глюк - для одной из «поз» ЭП не работает, есть проблемы с параметром id-tc26-gost-3410-12-256-paramSetA, а именно openssl подписывает таким ключом (то есть ключ вроде бы правильный и подходит к сертификату, потому что если ключ неправильный, например мусор - то openssl ругается по-другому) но проверка ЭП для ключей с такими параметрами с помощью openssl говорит — подпись неверна. Пока нет времени с этим разбираться. Вы про этот глюк говорите?

Я думаю, что дело не в openssl, и не в библиотеке, которая поддерживает ГОСТ (gost.dll) а в стыковке между ними. Как ни странно, чтобы gost.dll заработал с openssl нужно долго плясать с бубнами, если и то и другое собирать из исходников. А готового решения почему-то нет (я имею ввиду нет нигде с поддержкой id-tc26-gost-3410-12-256-paramSetA). Или это под Windows нет, а под Linux всё есть? Я лично под Windows пробовал искать, надо Linux последний накатить и по репозиториям пройтись. Тут уже Ubuntu 19.10 "Eoan Ermine" вышла, как время летит!

from privkey.

В итоге ключ с параметрами
1.2.643.7.1.2.1.1.1': 'id-tc26-gost-3410-12-256-paramSetA',
не работает — хотя OpenSSL его считывает как будто он подходит к сертификату, далее создает ЭП, но ЭП не проверяется.

А этот ключ как ни странно заработал!
'1.2.643.7.1.2.1.2.3': 'id-tc26-gost-3410-12-512-paramSetC',
Хотя там тоже кривые Эдвардса.

from privkey.

Неправильный ключ означает 1) используется неверный ключ из двух имеющихся в контейнере 2) у ключа неправильные параметры. Как я уже написал ранее, я эти проблемы в своем парсере решил после экспериментов и вдумчивого чтения RFC и спеков от ТК26. Еще одним источником информации для меня был gostCrypto, но он тоже создает несовместимый с КриптоПро ключ. Взаимная работа gost-engine и openssl - это совершенно отдельная история.

from privkey.

Спасибо, понятно! Я лично ТК-26 не читал и 5.0 версию почти не видел и с двумя ключами не работал. А зачем 2 ключа в одном контейнере? Для шифровалки и для ЭП отдельно что-ли? До чего дошёл прогресс!

from privkey.

Два ключа в контейнере видимо для совместимости с API провайдера в win32: AT_KEYEXCHANGE/AT_SIGNATURE, КриптоПро создает два ключа даже в очень старых своих версиях. Что интересно, КриптоПро для ЦП использует ключик AT_KEYEXCHANGE, соответственно для совместимости нужно использовать именно его.

from privkey.

Да, действительно для совместимости нужны 2 ключа.

И последний вопрос - а в Ваших экспериментах удалось ключ в позе '1.2.643.7.1.2.1.1.1': 'id-tc26-gost-3410-12-256-paramSetA', прикрутить к openssl после конвертации? Это же самый лучший ключ на данный момент. Потому что ключи 512 бит даром никому не нужны, а из 256 бит этот алг самый быстрый - на 10% быстрее, чем все остальные. И поддерживает ли его сейчас gostCrypto.js ? Год-два назад точно не поддерживал.

from privkey.

curve 1.2.643.7.1.2.1.1.1 в paramset поддерживается везде: openssl, gost-engine, gostCrypto. Стоит заметить, что gostCrypto не обновлялся давно и не смог прочитать ни одного из моих тестовых контейнеров КриптоПро, однако есть его форк, который читает все контейнера: nodejs-gost-crypto Александра Устименко. Ключи с длиной 512 бит используются банками повсеместно.

from privkey.

Ключи с длиной 512 бит используются банками повсеместно.

Ну я работаю на Московской бирже и в проме ни разу не встречал.

curve 1.2.643.7.1.2.1.1.1 в paramset поддерживается везде: openssl, gost-engine, gostCrypto.
Спасибо за наводку. Форк gostCrypto от Устименко (garex) я качнул, но поддержки моего проблемного ключа не увидел. Да, там есть oid 1.2.643.7.1.2.1.1.1 - но он ссылается на T-256-A, который в свою очередь ссылается на S-256-A

Это если я правильно понимаю эту строчку из файла gostSign.js :
ECGostParams['T-256-A'] = ECGostParams['S-256-A'];

А я же говорил, что не работают вот эти ключи (см ниже zip). Это кривые Эдвардса 256 бит. Их нет в gostCrypto вообще, а в gost-engine (плюс openssl) ЭП создается, но не проверяется. Посмотрите, пожалуйста, своей утилитой эти мои ключи - выкладываю mime64 для ZIP архива с ключами Крипто-Про:

-----BEGIN ZIP-----
UEsDBBQAAAAIAESofE3i4zDVYQAAAHYAAAAKAAAAaGVhZGVyLmtleTMoMchZwMXG
odXKzMSkysTIzMTmYKDOzMS6YIEiWJSdkZGN0UCUjRPMZmJkZIQJMzE1sTAAQRfH
Ie2TLq2cnF/XKBrIw4xi5mIRNhBs5DcyMDIwMDKyMACDKBaWExlhnABQSwMEFAAA
AAgARKh8TUckT2s9AAAAOAAAAAkAAABtYXNrcy5rZXkBOADH/zA2BCB4jC4gpoCY
hLAN3AllUSc8cCjdZqp5vqm7BJEO9V/RYwQMzGXHMnb0O5xi7R+4BAS6MhFZUEsD
BBQAAAAIAESofE1fcbtGKwAAACsAAAAIAAAAbmFtZS5rZXkz0BRTz0vRNTJOMjIw
MTMFMiyMdI3NjVJ0k9KSU3WNUxJNEw3NktNSDCwAUEsDBBQAAAAIAESofE1vybdx
JwAAACQAAAALAAAAcHJpbWFyeS5rZXkzUGJRmNKe8edyyyzbFKcs3UzGA87T/jZb
stSJrGszjjn7XGlqOQBQSwECHwAUAAAACABEqHxN4uMw1WEAAAB2AAAACgAkAAAA
AAAAACAAAAAAAAAAaGVhZGVyLmtleQoAIAAAAAAAAQAYAGfRAHtEh9QBFr1lnmCg
1QFjqgB7RIfUAVBLAQIfABQAAAAIAESofE1HJE9rPQAAADgAAAAJACQAAAAAAAAA
IAAAAIkAAABtYXNrcy5rZXkKACAAAAAAAAEAGABjqgB7RIfUAU7M855goNUB7+b/
ekSH1AFQSwECHwAUAAAACABEqHxNX3G7RisAAAArAAAACAAkAAAAAAAAACAAAADt
AAAAbmFtZS5rZXkKACAAAAAAAAEAGABDa/p6RIfUATegVZJgoNUBN6X5ekSH1AFQ
SwECHwAUAAAACABEqHxNb8m3cScAAAAkAAAACwAkAAAAAAAAACAAAAA+AQAAcHJp
bWFyeS5rZXkKACAAAAAAAAEAGACeSv96RIfUAUeH/npEh9QBR4f+ekSH1AFQSwUG
AAAAAAQABABuAQAAjgEAAAAA
-----END ZIP-----

Короче у меня не получилось с этим ключом работать через openssl - ЭП не проверяется!
Писал об этом выше.

А вот цепочка от него, на всякий случай, вдруг потребуется.
Это корневой, он обычный ГОСТ-2001 но это неважно.

-----BEGIN CERTIFICATE-----
MIIC1DCCAoOgAwIBAgIKMTUwMjU4NDQyNDAIBgYqhQMCAgMwgcIxCzAJBgNVBAYT
AlJVMRIwEAYDVQQIDAk3NyBNb3Njb3cxDzANBgNVBAcMBk1vc2NvdzEPMA0GA1UE
CQwGU3RyZWV0MQ4wDAYDVQQLDAVPdGRlbDEPMA0GA1UEBAwGSXZhbm92MQ0wCwYD
VQQqDARJdmFuMRAwDgYDVQQMDAdNYW5hZ2VyMSAwHgYDVQQDDBfQmtC+0YDQvdC1
0LLQvtC5IDIwMDFfQTEZMBcGCSqGSIb3DQEJARYKMTIzQDEyMy5ydTAeFw0xODEx
MjcwMTAxMDFaFw0yMDAyMjUwMTAxMDFaMIHCMQswCQYDVQQGEwJSVTESMBAGA1UE
CAwJNzcgTW9zY293MQ8wDQYDVQQHDAZNb3Njb3cxDzANBgNVBAkMBlN0cmVldDEO
MAwGA1UECwwFT3RkZWwxDzANBgNVBAQMBkl2YW5vdjENMAsGA1UEKgwESXZhbjEQ
MA4GA1UEDAwHTWFuYWdlcjEgMB4GA1UEAwwX0JrQvtGA0L3QtdCy0L7QuSAyMDAx
X0ExGTAXBgkqhkiG9w0BCQEWCjEyM0AxMjMucnUwYzAcBgYqhQMCAhMwEgYHKoUD
AgIjAQYHKoUDAgIeAQNDAARADKVunHga9AP0mOb5rWCXse1rcMcPua4APJzgtfS+
PXQk3SZhieI/wYrYEW3LC2EvJ+3lbjwAgMrX4R1vG8H3/KNXMFUwEwYDVR0lBAww
CgYIKwYBBQUHAwQwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAcYwHQYD
VR0OBBYEFOK1hyvKlkZtcyWyIxHOdFI7xbrNMAgGBiqFAwICAwNBAIVjeui5HZNi
F9wytRk8gjxFMPx9OTLqzs06Ab9ij90OJYXVmK5sF9KFKt4YCyCESiCghvYpLGWL
ISCr+P1TAo0=
-----END CERTIFICATE-----

И это сам серт от этого ключа:

-----BEGIN CERTIFICATE-----
MIIDxzCCA3agAwIBAgIKODQxNDMxMzQxMDAIBgYqhQMCAgMwgcIxCzAJBgNVBAYT
AlJVMRIwEAYDVQQIDAk3NyBNb3Njb3cxDzANBgNVBAcMBk1vc2NvdzEPMA0GA1UE
CQwGU3RyZWV0MQ4wDAYDVQQLDAVPdGRlbDEPMA0GA1UEBAwGSXZhbm92MQ0wCwYD
VQQqDARJdmFuMRAwDgYDVQQMDAdNYW5hZ2VyMSAwHgYDVQQDDBfQmtC+0YDQvdC1
0LLQvtC5IDIwMDFfQTEZMBcGCSqGSIb3DQEJARYKMTIzQDEyMy5ydTAeFw0xODEx
MjcwMTAxMDFaFw0yMDAyMjUwMTAxMDFaMIHCMQswCQYDVQQGEwJSVTESMBAGA1UE
CAwJNzcgTW9zY293MQ8wDQYDVQQHDAZNb3Njb3cxDzANBgNVBAkMBlN0cmVldDEO
MAwGA1UECwwFT3RkZWwxDzANBgNVBAQMBkl2YW5vdjENMAsGA1UEKgwESXZhbjEQ
MA4GA1UEDAwHTWFuYWdlcjEgMB4GA1UEAwwXT09PINCb0LXQvtC90LjQtCAyMDEy
X0QxGTAXBgkqhkiG9w0BCQEWCjEyM0AxMjMucnUwaDAhBggqhQMHAQEBATAVBgkq
hQMHAQIBAQEGCCqFAwcBAQICA0MABEDCK8lEhQkJ9d6102VdDMv/ti2zJLkyoF3W
5/CPqwYr5V+OP9kGpyZTKozidpGpei0pUPfyBffugb7XV1paHpEwo4IBQzCCAT8w
DgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBRI
NvXpD7VycnwbGl9CgRsTiHgIcjCB+AYDVR0jBIHwMIHtgBTitYcrypZGbXMlsiMR
znRSO8W6zaGByKSBxTCBwjELMAkGA1UEBhMCUlUxEjAQBgNVBAgMCTc3IE1vc2Nv
dzEPMA0GA1UEBwwGTW9zY293MQ8wDQYDVQQJDAZTdHJlZXQxDjAMBgNVBAsMBU90
ZGVsMQ8wDQYDVQQEDAZJdmFub3YxDTALBgNVBCoMBEl2YW4xEDAOBgNVBAwMB01h
bmFnZXIxIDAeBgNVBAMMF9Ca0L7RgNC90LXQstC+0LkgMjAwMV9BMRkwFwYJKoZI
hvcNAQkBFgoxMjNAMTIzLnJ1ggoxNTAyNTg0NDI0MAgGBiqFAwICAwNBAHvA7oOt
JovbH8Pce+nLZmrIb259QtKSJdxHmLt2q0ra4//MbwLKiO48ybg5yYVmikkMbwKK
Or3AOIfepH5d5iA=
-----END CERTIFICATE-----

Только смотрите быстрее, серты в 2020 году просрачиваются)

from privkey.

Я посмотрел бы на исходный контейнер, сертификат же мне для проверки не нужен, так как с помощью созданного ключа я генерирую самоподписанный сертификат средствами openssl+gost-engine.

from privkey.

Я посмотрел бы на исходный контейнер

Контейнер (файлы header.key primary.key) в zip файле, а zip закодирован в mime64 (он же base64 он же pem) см выше.

from privkey.

я генерирую самоподписанный сертификат средствами openssl+gost-engine

Кстати, надо это мне тоже попробовать, есть подозрение что если openssl ЭП не проверяет, то и серт не сделает.

from privkey.

Контейнер (файлы header.key primary.key) в zip файле, а zip закодирован в mime64 (он же base64 он же pem) см выше.
Спасибо. Какой версией КриптоПро создан этот контейнер? Моя программа ожидает увидеть полный набор primary/primary2 и masks/masks2, хотя primary2/masks2 это бэкап (хотя и зашифрован по-другому от primary/masks, но результат расшифровки идентичный в обоих парах), я проверяю результат расшифровки, чтобы оба ключа совпали. Чтобы моя программа заработала я скопировал masks в masks2 и primary в primary2, после этого программа успешно прочитала закрытый ключ (X: c2 2b c9 44 ... Y: 5f 8e 3f d9 ...) Создание ЦП я проверю позже.

from privkey.

Какой версией КриптоПро создан этот контейнер?

Я не знаю, мне год назад прислали для тестирования все позы, в том числе и эту 1.2.643.7.1.2.1.1.1 - см файл header.key

программа успешно прочитала закрытый ключ (X: c2 2b c9 44 ... Y: 5f 8e 3f d9 ...)

Что-то не то получилось. У меня выдает вот такое:

-----BEGIN PRIVATE KEY-----
MEoCAQAwIQYIKoUDBwEBAQEwFQYJKoUDBwECAQEBBggqhQMHAQECAgQiAiA96cXK
xS2z3RG+c/oPY1qUiOJLWVx+ngKG6OuUWrEdcQ==
-----END PRIVATE KEY-----

А в hex вот это:

А Вы делаете для него публичный ключ для проверки?
Там 8 байт можно сравнить с тем, что лежит в header.key и тем самым 100% проверить.
У меня 8 байт сходятся, поэтому в ключе я уверен.
Да и Крипто-Про с ним работает как часы. А вот openssl нет.
Хотя это год назад ещё проверялось, может быть, уже научили?

from privkey.

Ух, ошибочка вышла. X/Y это куски от вычисленного открытого ключа. Закрытый ключ начинается с 71 1d b1 5a. И да, я проверяю вычисленный открытый ключ с 8 байтами в контейнере. В контейнере 8 байт это c2 2b c9 44 85 09 09 f5

from privkey.

Спасибо за ответ.

1. С тех пор как я написал свой вопрос много воды утекло :) Я написал свой парсер контейнеров КриптоПро с расшифровкой закрытых ключей обоих типов (exchange/signature).

А можете пожалуйста выложить исходный код вашего парсера на github?

У меня тоже возникли проблемы с использованием данной утилиты, ни один из 5 контейнеров (3 из них получены от госуслуг для интеграции ЕСИА для тестов) не сконвертировались

from privkey.

А можете пожалуйста выложить исходный код вашего парсера на github?

У меня тоже возникли проблемы с использованием данной утилиты, ни один из 5 контейнеров (3 из них получены от госуслуг для интеграции ЕСИА для тестов) не сконвертировались

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

from privkey.

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

Хорошо, спасибо

Вроде нашёл способ конвертирования на gostcrypto.com с примерами и исходным кодом, тестовые контейнеры сконвертировались, надо потестить

from privkey.

Вроде нашёл способ конвертирования на gostcrypto.com с примерами и исходным кодом, тестовые контейнеры сконвертировались, надо потестить

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

from privkey.

Это я, Михаил, автор privkey - смотрю, тут такая дискуссия развернулась не на шутку ))

Данная утилита "privkey" возвращает can not read container from D:

Скорее всего, там у криптопрошников поменялось что-то в ASN1 формате, а утилита не разбирает формат, а просто считывает поля в порядке следования. Достаточно поменять их местами и будет "can not read container".

В идеале, конечно, хотелось бы получить Ваш ключ, тогда если этот ключ нормально грузит CryptoPro-CSP то смог бы поправить утилиту. Но я понимаю, что он секретный и Вы не пришлете все файлы - но может хотя бы вышлете свой header.key файл? Думаю, ошибка там, а header.key не секретный, там только сертификат (иногда) лежит.

Кстати, есть идея - убрать из утилиты privkey анализ header.key совсем, но тогда нужно будет вводить "параметры ключа" вручную. Но так как их штук 5 всего, можно все перебрать и тогда header.key получается и вовсе не нужен. Короче вот так можно сделать. Попробую на выходных.

С RSA всё работает

А что за RSA ? Разве ЕСИА умеет RSA ?

from privkey.

но может хотя бы вышлете свой header.key файл? Думаю, ошибка там, а header.key не секретный, там только сертификат (иногда) лежит.

скажите на какую почту, я пришлю

С RSA всё работает

А что за RSA ? Разве ЕСИА умеет RSA ?

я интегрировал ЕСИА на сайт в 2018 году и тогда она умела, и сейчас умеет.
С ноября 2019 запрещено грузить RSA сертификаты - подписывать всё ещё можно.
В 1 квартале 2020 года и подписывать уже нельзя станет. А тут какие-то 6 файлов приватного ключа, которые не понимает openssl и кроме какой-то платной утилиты от "Лисси" (которая вроде зачастую не работает даже) ничего нет. Так что такие утилиты как ваша - спасают

from privkey.

нашёл также утилиту https://github.com/kov-serg/get-cpcert , последний коммит совсем недавно и вроде даже возвращает сертификат+ключ, но при попытке подписать реквест до ЕСИА получаю ошибку error_description = "ESIA-007005: The client is not authorized to request an access token using this method." Не могу разобраться в чём проблема пока что. С RSA всё работает

с этой ошибкой разобрался, так что получилось выдернуть с помощью get-cpcert валидные сертификат и ключ и теперь всё работает/подписывается

from privkey.

скажите на какую почту, я пришлю

[email protected]

получилось выдернуть с помощью get-cpcert валидные сертификат и ключ

Отлично!

А я сейчас собрал openssl 1.1.1e + gost (под Windows с большими танцами с бубном, под ubuntu норм) и у меня наконец-то заработал параметр "кривые Эдвардса 256 бит" см выше, этот ключ я уже кидал в mime формате см ---- BEGIN ZIP --- если интересно.

Год назад не работало. Наука не стоит на месте )

from privkey.

[email protected]

отправил вам header.key

from privkey.

Спасибо, получил!
Вижу целых 3 сертификата, к такому нас жизнь не готовила))

Посмотрю, что можно сделать и тогда через пару дней закоммичу новую версию.

from privkey.

Поправил, сейчас ищет публичный ключ по всему файлу header.key
Должно работать всегда. А раньше искали public8 по фиксированному адресу:

Кроме того, добавил winfiles.rar где можно найти сборку для винды.

from privkey.

А я сейчас собрал openssl 1.1.1e + gost (под Windows с большими танцами с бубном,

Не поделитесь? Для пунктов 6 и 7

from privkey.

Плюсу, выложите, пожалуйста новую версию

from privkey.