02.04.2004 14:49:20Шифрование Ответов: 4
Игорь
Делаю так:

CryptAcquireContext( &m_hCryptProv, NULL, CP_DEF_PROV, PROV_GOST_DH, CRYPT_VERIFYCONTEXT );

CryptCreateHash( m_hCryptProv, CALG_GR3411, 0, 0, &m_hHash );
// Получаем хеш данных
CryptHashData( m_hHash, pbKey, dwKeyLen, 0 );
// Создаем ключ на полученном хеше
CryptDeriveKey( m_hCryptProv, CALG_G28147, m_hHash, 0, &m_hKey );
// Указываем что это потоковый алгоритм
DWORD dw = CRYPT_MODE_CFB;
CryptSetKeyParam( m_hKey, KP_MODE, (PBYTE) &dw, 0 );
// Шифруем
CryptEncrypt( m_hKey, 0, fFinal, 0, pbData, pdwDataSize, dwBufSize );

Для одних и тех же значений pbKey и pbData получаю разный шифротекст, и,
соответственно, не могу расшифровать. В чем дело?

Значение хеша для CALG_GR3411 всегда равно 32 байта?
 
Ответы:
02.04.2004 15:09:21Василий
Дело в том, что при каждом использовании ключа меняется значение синхровектора (IV). Поэтому, перед зашифрованием значение IV нужно сохранить, перед расшифрованием - установить.
Функции ..GetKeyParam, ..SetKeyParam, параметр KP_IV
02.04.2004 15:36:35Игорь
А как мне узнать значение этого IV на принимающей стороне? Да и вообще, это не правильно и противоречит документации, которая мне говорит, что я могу рассчитывать на выработку ОДИНАКОГО ключа для ОДИНАКОВЫХ данных. А тут ещё и синхровектор какой-то... Может есть способ обойтись без него?
И о размере хеша пожалуйста...
02.04.2004 16:41:55Игорь
С синхровектором разобрался, его можно обнулять, как это делает Microsoft Base Cryptographic Provider. Вообще, больше похоже на недоработку, чем на фичу.
Остался вопрос о хеше.
07.04.2004 18:46:02SiM
Это не недоработка и не фича, это ГОСТ Р 34.11-94