вычисление обменного хэша для ecdsa-sha2-nistp256 - PullRequest
Новая
       6

вычисление обменного хэша для ecdsa-sha2-nistp256

0 голосов
/ 27 апреля 2018

Я пишу код для SSH-сервера и не могу пройти часть ответа на обмен ключами Диффи-Хеллмана по эллиптической кривой. Клиент также закрывает соединение и говорит: «Ключ хоста не соответствует поставленной подписи».

Я использую замазку в качестве клиента, а микроконтроллер PIC использует код сервера.

Из RFC 5656 [Интеграция алгоритма SSH ECC]:

"Хеш H формируется путем применения алгоритма HASH к объединение следующего: 

  string   V_C, client's identification string (CR and LF excluded)
  string   V_S, server's identification string (CR and LF excluded)
  string   I_C, payload of the client's SSH_MSG_KEXINIT
  string   I_S, payload of the server's SSH_MSG_KEXINIT
  string   K_S, server's public host key
  string   Q_C, client's ephemeral public key octet string
  string   Q_S, server's ephemeral public key octet string
  mpint    K,   shared secret

"

алгоритм хост-ключа и алгоритм обмена ключами - ecdsa-sha2-nistp256 и ecdh-sha2-nistp256 соответственно.

ссылаясь на RFC 4251 для представления типов данных, а также исходный код в openSHH (openBSD), это то, что я конкатенировал.

  1. 4 байта для длины V_C, за которой следует V_C
  2. 4 байта для длины V_S, за которой следует V_S
  3. 4 байта для длины I_C, за которой следует I_C (полезная нагрузка от кода сообщения до начала произвольного заполнения)
  4. 4 байта для длины I_S, за которой следует I_S (полезная нагрузка от кода сообщения до начала произвольного заполнения)
  5. 4 байта для длины K_S, за которой следует K_S (для K_S я использовал ту же группу байтов, которая используется для вычисления отпечатка пальца)
  6. 4 байта для длины Q_C, за которой следует Q_C (я использовал несжатую строку длиной 65 - 04 || X-координата || Y-координата)
  7. 4 байта для длины Q_S, за которой следует Q_S
  8. 4 байта для длины K, за которой следует K (длина равна 32 или 33 в зависимости от того, установлен ведущий бит или нет. Если он установлен, то K предшествует байт 00)

После объединения я хэшировал его с SHA256, потому что я использую NISTP256. SHA256 выводит 32 байта, что является размером кривой, поэтому я беру весь вывод SHA256 и выполняю алгоритм подписи на нем.

Я никогда не смогу получить правильную подпись из конкатенации моего сообщения.

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

Это заставляет меня предположить, что ошибка в конкатенации хеша обмена.

Любая помощь очень ценится, спасибо.

1 Ответ

0 голосов
/ 28 апреля 2018

Генерация подписи ECDSA является недетерминированной, то есть часть входных данных является хешем, а часть входных данных состоит из случайных байтов. Поэтому, что бы вы ни делали, вы всегда будете получать другую подпись. Все в порядке, потому что проверка подписи все еще будет работать.

Единственный способ получить повторяющуюся подпись - связываться с генератором случайных чисел (во время тестирования вы не хотите подписывать два значения одним и тем же случайным числом: вы выставляете закрытый ключ!).

...