(2018-04-02 18:16:47 отредактировано Аникушин Евгений)

Re: Работа с функциями библиотеки rtPKCS11ECP

Всё верно. Единственное что проверить это с нашей библиотекой у вас не получится, так как там нет поддержки тестовых параметров подписи (будет ошибка при создании ключа). Но для понимания того как работать с данными в формате big-endian всё же приведу пример:

А.1 Пример 1. для ГОСТ34.10-2012(256)

1. Для импорта открытого ключа, нужно разворачивать координаты, а не весь ключ полностью:
X:7F2B49E270DB6D90D8595BEC458B50C58585BA1D4E9B788F6689DBD8E56FD80B
Y:26F1B489D6701DD185C8413A977B3CBBAF64D1C593D26627DFFB101A87FF77DA

CK_BYTE public_key[] = {
0x0b, 0xd8, 0x6f, 0xe5, 0xd8, 0xdb, 0x89, 0x66, 0x8f, 0x78, 0x9b, 0x4e, 0x1d, 0xba, 0x85, 0x85,
0xc5, 0x50, 0x8b, 0x45, 0xec, 0x5b, 0x59, 0xd8, 0x90, 0x6d, 0xdb, 0x70, 0xe2, 0x49, 0x2b, 0x7f,

0xda, 0x77, 0xff, 0x87, 0x1a, 0x10, 0xfb, 0xdf, 0x27, 0x66, 0xd2, 0x93, 0xc5, 0xd1, 0x64, 0xaf, 
0xbb, 0x3c, 0x7b, 0x97, 0x3a, 0x41, 0xc8, 0x85, 0xd1, 0x1d, 0x70, 0xd6, 0x89, 0xb4, 0xf1, 0x26
};

Также значение параметров подписи в атрибутах ключа должно соответствовать тестовым "1.2.643.2.2.35.0"

CK_BYTE gost_3410_test_parameters[] = {
 0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x00
 };

CK_ATTRIBUTE sign_oid_attribute = {
 CKA_GOSTR3410_PARAMS, gostR3410params_oid, sizeof(gostR3410params_oid)
 };

2. Хеш разворачивается без особенностей
H: 2DFBC1B372D89A1188C09C52E0EEC61FCE52032AB1022E8E67ECE6672B043EE5

CK_BYTE hash[] = {
0xe5, 0x3e, 0x04, 0x2b, 0x67, 0xe6, 0xec, 0x67, 0x8e, 0x2e, 0x02, 0xb1, 0x2a, 0x03, 0x52, 0xce, 
0x1f, 0xc6, 0xee, 0xe0, 0x52, 0x9c, 0xc0, 0x88, 0x11, 0x9a, 0xd8, 0x72, 0xb3, 0xc1, 0xfb, 0x2d
};

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40

CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Замечу, что большинство софта использует при работе "little-endian" (в ГОСТ всё же big-endian), при работе с тем же CryptoPro данные видоизменять никак не нужно.

Re: Работа с функциями библиотеки rtPKCS11ECP

В панели управления записан открытый ключ в виде:

3134BE49E99351EBD0F249D488DBDA754E42AB20D5B34B495B3AA16F2417DB28D4963852C569440EFE05C5F4A5028C4C47E8CA366C0ED17F55EED778F83ED65E
D926D5E1BAEC93196C07ADFD412C64B064446B57333132935C32F63EB736789F30E9F8B193AC3EFF20F7E9F76F5E0E796B17F16E74753D7695FF7BE291D3248B

Ключ на сервере хранится перевернутыми половинами:

5ED63EF878D7EE557FD10E6C36CAE8474C8C02A5F4C505FE0E4469C5523896D428DB17246FA13A5B494BB3D520AB424E75DADB88D449F2D0EB5193E949BE3431
8B24D391E27BFF95763D75746EF1176B790E5E6FF7E9F720FF3EAC93B1F8E9309F7836B73EF6325C93323133576B4464B0642C41FDAD076C1993ECBAE1D526D9

На сервере реализована схема в точности соответствующая стандарту (big endian). Параметры схемы:

p:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFDC7

a:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFDC4

b:
E8C2505DEDFC86DDC1BD0B2B6667F1DA
34B82574761CB0E879BD081CFD0B6265
EE3CB090F30D27614CB4574010DA90DD
862EF9D4EBEE4761503190785A71C760

q 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
27E69532F48D89116FF22B8D4E056060
9B4B38ABFAD2B85DCACDB1411F10B275

x = 3

y:
7503CFE87A836AE3A61B8816E25450E6
CE5E1C93ACF1ABC1778064FDCBEFA921
DF1626BE4FD036E93D75E6A50E3A41E9
8028FE5FC235F5B889A589CB5215F2A4

Для подписи используется механизм

ckmGOST_34_10_2012_512_with_34_11_2012_512  = { CKM_GOSTR3410_WITH_GOSTR3411_12_512, NULL_PTR, 0 };

При подписи строки "Hello" она разворачивается и передается в функцию C_Sign, после чего на выходе получается подпись:

CCC4A8437EA39BD0AC5D53CE8EEE8F01DD2401A10AEC46F3DEF414BFCD51A72ABF001CB6A49CB1B3D635AAB8A66643D7B7DBAC7BC54009103438EF9C3F218DC7
BEF498A10D0A3971567A165085356F8882735054686836C83FBC5518ADD9083338763881BC0B10486E20079388DD4E89F18822ED52639E6E092463E7DD807D34

Разворачиваются половины подписи:

C78D213F9CEF3834100940C57BACDBB7D74366A6B8AA35D6B3B19CA4B61C00BF2AA751CDBF14F4DEF346EC0AA10124DD018FEE8ECE535DACD09BA37E43A8C4CC
347D80DDE76324096E9E6352ED2288F1894EDD889307206E48100BBC813876383308D9AD1855BC3FC836686854507382886F358550167A5671390A0DA198F4BE

Затем происходит отправка данной подписи на сервер для проверки. При этом результат проверки отрицательный и подпись не принимается.

Аникушин Евгений пишет:

Всё верно. Единственное что проверить это с нашей библиотекой у вас не получится, так как там нет поддержки тестовых параметров подписи (будет ошибка при создании ключа). Но для понимания того как работать с данными в формате big-endian всё же приведу пример:

А.1 Пример 1. для ГОСТ34.10-2012(256)

1. Для импорта открытого ключа, нужно разворачивать координаты, а не весь ключ полностью:
X:7F2B49E270DB6D90D8595BEC458B50C58585BA1D4E9B788F6689DBD8E56FD80B
Y:26F1B489D6701DD185C8413A977B3CBBAF64D1C593D26627DFFB101A87FF77DA

CK_BYTE public_key[] = {
0x0b, 0xd8, 0x6f, 0xe5, 0xd8, 0xdb, 0x89, 0x66, 0x8f, 0x78, 0x9b, 0x4e, 0x1d, 0xba, 0x85, 0x85,
0xc5, 0x50, 0x8b, 0x45, 0xec, 0x5b, 0x59, 0xd8, 0x90, 0x6d, 0xdb, 0x70, 0xe2, 0x49, 0x2b, 0x7f,

0xda, 0x77, 0xff, 0x87, 0x1a, 0x10, 0xfb, 0xdf, 0x27, 0x66, 0xd2, 0x93, 0xc5, 0xd1, 0x64, 0xaf, 
0xbb, 0x3c, 0x7b, 0x97, 0x3a, 0x41, 0xc8, 0x85, 0xd1, 0x1d, 0x70, 0xd6, 0x89, 0xb4, 0xf1, 0x26
};

Также значение параметров подписи в атрибутах ключа должно соответствовать тестовым "1.2.643.2.2.35.0"

CK_BYTE gost_3410_test_parameters[] = {
 0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x23, 0x00
 };

CK_ATTRIBUTE sign_oid_attribute = {
 CKA_GOSTR3410_PARAMS, gostR3410params_oid, sizeof(gostR3410params_oid)
 };

2. Хеш разворачивается без особенностей
H: 2DFBC1B372D89A1188C09C52E0EEC61FCE52032AB1022E8E67ECE6672B043EE5

CK_BYTE hash[] = {
0xe5, 0x3e, 0x04, 0x2b, 0x67, 0xe6, 0xec, 0x67, 0x8e, 0x2e, 0x02, 0xb1, 0x2a, 0x03, 0x52, 0xce, 
0x1f, 0xc6, 0xee, 0xe0, 0x52, 0x9c, 0xc0, 0x88, 0x11, 0x9a, 0xd8, 0x72, 0xb3, 0xc1, 0xfb, 0x2d
};

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40

CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Замечу, что большинство софта использует при работе "little-endian" (в ГОСТ всё же big-endian), при работе с тем же CryptoPro данные видоизменять никак не нужно.

(2018-04-04 15:13:42 отредактировано Аникушин Евгений)

Re: Работа с функциями библиотеки rtPKCS11ECP

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40

CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:

pkcs-11v2-30m1-d7 пишет:

The signature octets correspond to the concatenation of the
GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
section 2.2.2.

Аналогично реализован и ГОСТ34.10-2012. То есть C_Sign вернёт

CK_BYTE sign[] = {
  0x01, 0x45, 0x6c, 0x64, 0xba, 0x46, 0x42, 0xa1, 0x65, 0x3c, 0x23, 0x5a, 0x98, 0xa6, 0x02, 0x49,
  0xbc, 0xd6, 0xd3, 0xf7, 0x46, 0xb6, 0x31, 0xdf, 0x92, 0x80, 0x14, 0xf6, 0xc5, 0xbf, 0x9c, 0x40,
  
  0x41, 0xaa, 0x28, 0xd2, 0xf1, 0xab, 0x14, 0x82, 0x80, 0xcd, 0x9e, 0xd5, 0x6f, 0xed, 0xa4, 0x19,
  0x74, 0x05, 0x35, 0x54, 0xa4, 0x27, 0x67, 0xb8, 0x3a, 0xd0, 0x43, 0xfd, 0x39, 0xdc, 0x04, 0x93,
}

По вашему примеру с "КриптоПро А". К сожалению пока проверка не сходится и на самом токене. Возможно в предоставленные данные закралась ошибка ? или при подписи использовалась другая ключевая пара ?

CK_BYTE message[] = {
 0x00, 0x6f, 0x6c, 0x6c, 0x65, 0x48
}

C_Digest(...)

hash[] = {
 0xB3, 0x9D, 0xDB, 0x1C, 0x9E, 0x03, 0x27, 0xDD, 0x20, 0x8D, 0x51, 0xFD, 0xD8, 0x5D, 0xD9, 0x53,
 0x3B, 0x4E, 0xBD, 0x5D, 0x37, 0xA6, 0xCA, 0xD9, 0xCF, 0xBC, 0x01, 0xA5, 0x90, 0xEE, 0xFC, 0xB5,
 0xF5, 0xD6, 0xE7, 0x78, 0xB7, 0xFE, 0xA9, 0x2A, 0x8D, 0x5B, 0x9F, 0xA4, 0x30, 0xD0, 0x4D, 0x1D,
 0x98, 0xA7, 0xAF, 0x85, 0x00, 0xF3, 0x91, 0x41, 0x91, 0x32, 0x22, 0x30, 0x04, 0xB7, 0xB2, 0x2E 
};

signature[] = {
 0xCC, 0xC4, 0xA8, 0x43, 0x7E, 0xA3, 0x9B, 0xD0, 0xAC, 0x5D, 0x53, 0xCE, 0x8E, 0xEE, 0x8F, 0x01,
 0xDD, 0x24, 0x01, 0xA1, 0x0A, 0xEC, 0x46, 0xF3, 0xDE, 0xF4, 0x14, 0xBF, 0xCD, 0x51, 0xA7, 0x2A, 
 0xBF, 0x00, 0x1C, 0xB6, 0xA4, 0x9C, 0xB1, 0xB3, 0xD6, 0x35, 0xAA, 0xB8, 0xA6, 0x66, 0x43, 0xD7,
 0xB7, 0xDB, 0xAC, 0x7B, 0xC5, 0x40, 0x09, 0x10, 0x34, 0x38, 0xEF, 0x9C, 0x3F, 0x21, 0x8D, 0xC7,
 
 0xBE, 0xF4, 0x98, 0xA1, 0x0D, 0x0A, 0x39, 0x71, 0x56, 0x7A, 0x16, 0x50, 0x85, 0x35, 0x6F, 0x88,
 0x82, 0x73, 0x50, 0x54, 0x68, 0x68, 0x36, 0xC8, 0x3F, 0xBC, 0x55, 0x18, 0xAD, 0xD9, 0x08, 0x33,
 0x38, 0x76, 0x38, 0x81, 0xBC, 0x0B, 0x10, 0x48, 0x6E, 0x20, 0x07, 0x93, 0x88, 0xDD, 0x4E, 0x89,
 0xF1, 0x88, 0x22, 0xED, 0x52, 0x63, 0x9E, 0x6E, 0x09, 0x24, 0x63, 0xE7, 0xDD, 0x80, 0x7D, 0x34 };

C_Verify(...) = 0xC0 (CKR_SIGNATURE_INVALID)

Re: Работа с функциями библиотеки rtPKCS11ECP

При развороте строки "Hello" получается последовательность без нуля в начале:

0x6f, 0x6c, 0x6c, 0x65, 0x48

Вообще функция подписи выглядит так:

{

    returnValue = pFunctionList->C_SignInit(hSession,         
                                            &ckmGOST_34_10_2012_512_with_34_11_2012_512 ,   
                                            *hPrivateKey);      

    char* str = QStringToCharArray(data);

    std::reverse(str, str + strlen(str));

    CK_BYTE_PTR pbtSignature = NULL_PTR;               
    CK_ULONG ulSignatureSize = 0;

    returnValue = pFunctionList->C_Sign(hSession,           
                                        (CK_BYTE_PTR)str,           
                                        strlen(str),      
                                        pbtSignature,      
                                        &ulSignatureSize);  

    pbtSignature = (CK_BYTE*)malloc(ulSignatureSize);
    memset( pbtSignature, 0, ulSignatureSize * sizeof(CK_BYTE));
    returnValue = pFunctionList->C_Sign(hSession,
                                        (CK_BYTE_PTR)str,
                                        strlen(str),
                                        pbtSignature,
                                        &ulSignatureSize);

    QByteArray result = QByteArray::fromRawData((const char*)pbtSignature, ulSignatureSize);

    std::reverse(result.begin(), result.begin() + result.length() / 2);
    std::reverse(result.begin() + result.length() / 2, result.end());
}

Данные подписаны тем же ключом. Результат хеширования неразвернутый (совпадает с развернутым хэшом сервера):

E08F335F5D02A6F1E70ABDDAD6EEE020C9E9DBD6307E28EEA9A126A3BC246612CEFBC6FC9E7A242FD7AE90D19AC8E5A2F63E12723E53A0AC2F17A24616995827

Подпись на выходе C_Sign:

236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E
E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083
Аникушин Евгений пишет:

3. Отдельно разворачиваем двоичные вектора составляющие подпись
r: 41AA28D2F1AB148280CD9ED56FEDA41974053554A42767B83AD043FD39DC0493
s: 1456C64BA4642A1653C235A98A60249BCD6D3F746B631DF928014F6C5BF9C40

CK_BYTE sign[] = {
0x93, 0x04, 0xdc, 0x39, 0xfd, 0x43, 0xd0, 0x3a, 0xb8, 0x67, 0x27, 0xa4, 0x54, 0x35, 0x05, 0x74,
0x19, 0xa4, 0xed, 0x6f, 0xd5, 0x9e, 0xcd, 0x80, 0x82, 0x14, 0xab, 0xf1, 0xd2, 0x28, 0xaa, 0x41,

0x40, 0x9c, 0xbf, 0xc5, 0xf6, 0x14, 0x80, 0x92, 0xdf, 0x31, 0xb6, 0x46, 0xf7, 0xd3, 0xd6, 0xbc,
0x49, 0x02, 0xa6, 0x98, 0x5a, 0x23, 0x3c, 0x65, 0xa1, 0x42, 0x46, 0xba, 0x64, 0x6c, 0x45, 0x01
};

Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:

pkcs-11v2-30m1-d7 пишет:

The signature octets correspond to the concatenation of the
GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
section 2.2.2.

Аналогично реализован и ГОСТ34.10-2012. То есть C_Sign вернёт

CK_BYTE sign[] = {
  0x01, 0x45, 0x6c, 0x64, 0xba, 0x46, 0x42, 0xa1, 0x65, 0x3c, 0x23, 0x5a, 0x98, 0xa6, 0x02, 0x49,
  0xbc, 0xd6, 0xd3, 0xf7, 0x46, 0xb6, 0x31, 0xdf, 0x92, 0x80, 0x14, 0xf6, 0xc5, 0xbf, 0x9c, 0x40,
  
  0x41, 0xaa, 0x28, 0xd2, 0xf1, 0xab, 0x14, 0x82, 0x80, 0xcd, 0x9e, 0xd5, 0x6f, 0xed, 0xa4, 0x19,
  0x74, 0x05, 0x35, 0x54, 0xa4, 0x27, 0x67, 0xb8, 0x3a, 0xd0, 0x43, 0xfd, 0x39, 0xdc, 0x04, 0x93,
}

По вашему примеру с "КриптоПро А". К сожалению пока проверка не сходится и на самом токене. Возможно в предоставленные данные закралась ошибка ? или при подписи использовалась другая ключевая пара ?

CK_BYTE message[] = {
 0x00, 0x6f, 0x6c, 0x6c, 0x65, 0x48
}

C_Digest(...)

hash[] = {
 0xB3, 0x9D, 0xDB, 0x1C, 0x9E, 0x03, 0x27, 0xDD, 0x20, 0x8D, 0x51, 0xFD, 0xD8, 0x5D, 0xD9, 0x53,
 0x3B, 0x4E, 0xBD, 0x5D, 0x37, 0xA6, 0xCA, 0xD9, 0xCF, 0xBC, 0x01, 0xA5, 0x90, 0xEE, 0xFC, 0xB5,
 0xF5, 0xD6, 0xE7, 0x78, 0xB7, 0xFE, 0xA9, 0x2A, 0x8D, 0x5B, 0x9F, 0xA4, 0x30, 0xD0, 0x4D, 0x1D,
 0x98, 0xA7, 0xAF, 0x85, 0x00, 0xF3, 0x91, 0x41, 0x91, 0x32, 0x22, 0x30, 0x04, 0xB7, 0xB2, 0x2E 
};

signature[] = {
 0xCC, 0xC4, 0xA8, 0x43, 0x7E, 0xA3, 0x9B, 0xD0, 0xAC, 0x5D, 0x53, 0xCE, 0x8E, 0xEE, 0x8F, 0x01,
 0xDD, 0x24, 0x01, 0xA1, 0x0A, 0xEC, 0x46, 0xF3, 0xDE, 0xF4, 0x14, 0xBF, 0xCD, 0x51, 0xA7, 0x2A, 
 0xBF, 0x00, 0x1C, 0xB6, 0xA4, 0x9C, 0xB1, 0xB3, 0xD6, 0x35, 0xAA, 0xB8, 0xA6, 0x66, 0x43, 0xD7,
 0xB7, 0xDB, 0xAC, 0x7B, 0xC5, 0x40, 0x09, 0x10, 0x34, 0x38, 0xEF, 0x9C, 0x3F, 0x21, 0x8D, 0xC7,
 
 0xBE, 0xF4, 0x98, 0xA1, 0x0D, 0x0A, 0x39, 0x71, 0x56, 0x7A, 0x16, 0x50, 0x85, 0x35, 0x6F, 0x88,
 0x82, 0x73, 0x50, 0x54, 0x68, 0x68, 0x36, 0xC8, 0x3F, 0xBC, 0x55, 0x18, 0xAD, 0xD9, 0x08, 0x33,
 0x38, 0x76, 0x38, 0x81, 0xBC, 0x0B, 0x10, 0x48, 0x6E, 0x20, 0x07, 0x93, 0x88, 0xDD, 0x4E, 0x89,
 0xF1, 0x88, 0x22, 0xED, 0x52, 0x63, 0x9E, 0x6E, 0x09, 0x24, 0x63, 0xE7, 0xDD, 0x80, 0x7D, 0x34 };

C_Verify(...) = 0xC0 (CKR_SIGNATURE_INVALID)

Re: Работа с функциями библиотеки rtPKCS11ECP

Аникушин Евгений пишет:

Здесь не до конца был прав, данные с токена возвращаются в таком виде, но в PKCS дополнительно разворачиваются, чтобы соответстовать стандарту:

pkcs-11v2-30m1-d7  пишет:

    The signature octets correspond to the concatenation of the
    GOST R 34.10-2001 values s and r’, both represented as a 32 bytes octet string in big
    endian order with the most significant byte first [RFC 4490] section 3.2, and [RFC 4491]
    section 2.2.2.

Значит для при таком значении подписи с токена

Michael Falcone пишет:

Подпись на выходе C_Sign:
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E
E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083

на сервер нужно отправлять

E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E

Re: Работа с функциями библиотеки rtPKCS11ECP

Да, теперь все заработало правильно, спасибо!

Аникушин Евгений пишет:

на сервер нужно отправлять

E769E42D16103DEF3D1AFAFFA5ED47A871289BE0F4F00669B75AD8E29301B7C67A00082C532163B175A87047B107D2A88C93FAC3F55FBC4981DB05C38911C083
236914E88238DDA00A5B4B8AE084511F475262E9EC44A53D9334429E6F9AE7FF2AF0C10CB0A66CBC6794C7BD282A5A5790BA38C85736E59ACD93FE54BB8AF05E

Re: Работа с функциями библиотеки rtPKCS11ECP

Добрый день!
У вас на тестовом центре регистрации http://ra.rutoken.ru/#/  реализована возможность формирования запроса на сертификат для ГОСТ 34.10-2012 с длиной закрытого ключа 512 бит.
Но в существующем релизе SDK  функция C_EX_CreateCSR поддерживает только алгоритмы  ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012 (256 бит) (см. CreateCSR-PKCS10-2012.c).

Подскажите, пожалуйста, когда ждать обновление SDK в этом вопросе?

Re: Работа с функциями библиотеки rtPKCS11ECP

Добрый день, wwago.

Да, обновление запланировано и выйдет ориентировочно к середине года.
Однако, мы не рекомендуем пользоваться PKCS#11 интерфейсом для создания запросов, гораздо лучше для этого подходит более высокоуровневый интерфейс PKI-Core. В нем кстати поддержка длинных ключей реализована уже давно.