Предварительная тайна сглаживания при использовании обмена ключами Диффи-Хеллмана

Я пытаюсь реализовать DHE_DSS в пакет go crypto/tls. К сожалению, я не могу заставить PreMasterSecret (Z) быть таким же, мой основной рабочий процесс:

Сообщение об обмене ключа сервера приема

  • Выдержка P, G, Ys
  • Проверить использование цифровой подписи

Подготовить сообщение об обмене ключами клиента

  • Создать клиент Xc
  • Генерация Yc (Yc = G ^ Xc% P)
  • Создать Z (Z = Ys ^ Xc% P)
  • Отправить обратно Yc, упакованный следующим образом:
ckx := make([]byte, len(yC)+2)
ckx[0] = byte(len(Yc)>>8)
ckx[1] = byte(len(Yc))
copy(ckx[2:], yBytes)

Однако, когда я отлаживаю это с помощью gnutls-serv, оба PreMasterSecrets (Z) отличаются. Нужно ли мне подписать возвращенный Yc, или, может быть, упаковать его по-другому? Я не вижу ничего в RFC 5246, чтобы предложить это.

< - EDIT →

Вот патч моих изменений:

https://08766345559465695203.googlegroups.com/attach/48587532c74b4348/crypto.patch?part=4&view=1&vt=ANaJVrHbwydqEZc3zjUWqQ5C8Q5zEkWXZLdL0w6JJG3HYntOlBurUTY7mc9xR9OTfE0bJxs4eeL5a5SGd2jj9eIfXcwJQgLvJchXOgkYKBBynbPfshY8kuQ

Ответы

Ответ 1

Обмен ключами клиента будет содержать:

length (2 bytes) --> Y_C (in plain text)

Я реализовал TLS в Java, и я придерживаюсь той же структуры и отлично работает для меня.

Нужно ли мне подписать возвращаемый Yc?

Нет нет необходимости подписывать общедоступное значение клиента DH, оно передается простым текстом.

Вы можете взять pcap и проверить, переносятся ли те же значения в пакете. Кроме того, если GNU TLS имеет регистратор для печати полученного Y_C, вы можете проверить, получены ли правильные данные.

Если в случае, если вы все еще получаете разный секрет Pre-Master, тогда, похоже, возникает проблема с логикой генерации секретности.