Статус: Сотрудник
Группы: Участники
Зарегистрирован: 17.10.2010(UTC) Сообщений: 147  Откуда: КРИПТО-ПРО Сказал «Спасибо»: 2 раз
Поблагодарили: 10 раз в 9 постах
|
А в преведенном примере KEK в явном (да и в неявном...) виде не фигурирует нигде. agr_key - это никак не KEK (отсюда и название пемеренной :-) ). Это фактически какой-то промежуточный ключик, выработанный с использованием открытого отправителя и закрытого получателя. А вот потоооом, в вызове CryptImportKey(hProv, (BYTE*)blob, REAL_CRYPT_SIMPLEBLOB_LEN, agr_key,CRYPT_EXPORTABLE, &premaster_key); И UKM используется (из начала блоба), и K(x,y, UKM) вычисляется, и KEK = GOST3411(K(x,y, UKM)) вычисляется, и заодно еще и премастер из блоба выковыривается с использованием этого KEK. Ну оочень насыщенная функция получается :-) P.S. Разработчики могут поправить. Отредактировано пользователем 30 мая 2011 г. 17:33:08(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.05.2011(UTC)
Сообщений: 6
Откуда: Россия
|
Спасибо за ответ!
Возникает очень интересный вопрос, что же тогда такое ключ согласования и зачем он собственно нужен?
Дело в том, что, насколько я знаю, для получения полезной сущности на базе открытого ключа удалённой стороны и своего закрытого ключа как раз и нужен UKM.
В противном случае ничего полезного получить нельзя. Поэтому мне совершенно неясно, что же такое ключ согласования и как его потом преобразовать в KEK?
Как мне кажется, ключ согласования - это просто некая пустышка (набор параметров). На этапе его получения не производится никаких криптографических операций.
А вот все криптографические операции по получению KEK выполняются уже после.
Возможно, я не прав. Очень интересно узнать, что же всё таки представляет из себя таинственный ключ согласования.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.05.2011(UTC)
Сообщений: 6
Откуда: Россия
|
Провёл несколько экспериментов.
Похоже, что я не прав в своём предположении.
Взял "Пример на экспортирование сессионного ключа с использованием структуры BLOB" из КриптоПро SDK.
Перед и после операцией получения ключа согласования (CryptImportKey) поставил getch().
Выяснилось, что пароль (PIN) для доступа к контейнеру запрашивается как раз в вызове CryptImportKey при получении ключа согласования. На этом этапе задать UKM нельзя. По крайней мере непонятно, как это сделать. Если после вызова CryptImportKey удалить контейнер, то программа всё равно успешно отрабатывает до конца. Таким образом, именно при получении ключа согласования на базе своего закрытого ключа и чужого открытого и вырабатывается разделяемый секрет. Но для выработки разделяемого секрета в соответствии с VKO GOST R 34.10-2001 необходим UKM.
Получается совершенно непонятная ситуация - разделяемый секрет получается при выработке ключа согласования, но необходимый для этой операции UKM задать нельзя.
Кто-нибудь может объяснить как задать UKM, либо указать в чём я не прав?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 17.10.2010(UTC) Сообщений: 147 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 2 раз
Поблагодарили: 10 раз в 9 постах
|
UKM задается значением в начале импортируемого блоба премастера.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.05.2011(UTC)
Сообщений: 6
Откуда: Россия
|
Это я понял.
Как сделать, чтобы всё работало на КриптоПро через Crypo API мне ясно.
Меня просто интересует как это реализовано.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.05.2011(UTC)
Сообщений: 6
Откуда: Россия
|
Это я понял.
Как сделать, чтобы всё работало на КриптоПро через Crypto API мне ясно.
Меня просто интересует как это реализовано.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 17.10.2010(UTC) Сообщений: 147 Откуда: КРИПТО-ПРО Сказал «Спасибо»: 2 раз
Поблагодарили: 10 раз в 9 постах
|
Ну так реализуй сам - разницы наверняка почти не будет! Начать можно с реализации операции вычисления кратной точки кривой. Там уже и понятно станет, нужно ли UKM для домножения на закрытый ключ получателя, или можно и "потом" домножить. Отредактировано пользователем 31 мая 2011 г. 22:43:15(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 30.05.2011(UTC)
Сообщений: 6
Откуда: Россия
|
В том то и дело, что без UKM похоже нельзя:
VKO GOST R 34.10-2001 (RFC 4357):
This algorithm creates a key encryption key (KEK) using 64 bit UKM,
the sender's private key, and the recipient's public key (or the
reverse of the latter pair).
1) Let K(x,y,UKM) = ((UKM*x)(mod q)) . (y.P) (512 bit), where
x - sender's private key (256 bit)
x.P - sender's public key (512 bit)
y - recipient's private key (256 bit)
y.P - recipient's public key (512 bit)
UKM - non-zero integer, produced as in step 2 p. 6.1 [GOSTR341001]
P - base point on the elliptic curve (two 256-bit coordinates)
UKM*x - x multiplied by UKM as integers
x.P - a multiple point
2) Calculate a 256-bit hash of K(x,y,UKM):
KEK(x,y,UKM) = gostR3411 (K(x,y,UKM))
Keypairs (x,x.P) and (y,y.P) MUST comply with [GOSTR341001].
This algorithm MUST NOT be used when x.P = P, y.P = P
Таким образом, я и не могу понять, что можно сделать на этапе выработки ключа согласования кроме как закэшировть закрытый ключ (обращение к нему идёт именно на этом этапе).
Но если речь идёт о кэшировании ключа, то как это может работать с аппаратными токенами?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
