Le secret pré-maître est mal adapté lors de la mise en œuvre de l'échange de clés Diffie-Hellman.

Question

J'essaie d'implémenter DHE_DSS dans le paquet crypto/tls de Go. Malheureusement, je n'arrive pas à faire en sorte que le PreMasterSecret (Z) soit le même, mon flux de travail de base est le suivant :

Recevoir le message d'échange de clés du serveur

• Extraire P, G, Ys
• Vérifier en utilisant la signature numérique fournie

Préparer le message d'échange de clés du client

• Créer le Xc du client
• Générer Yc (Yc = G^Xc % P)
• Générer Z (Z = Ys^Xc % P)

• Renvoyez Yc, emballé comme ça :

  ckx := make([]byte, len(yC)+2) ckx[0] = byte(len(Yc)>>8) ckx[1] = byte(len(Yc)) copy(ckx[2:], yBytes)

Cependant, lorsque je débogue avec gnutls-serv, les deux PreMasterSecrets (Z) sont différents. Dois-je signer l'Yc retourné, ou peut-être l'emballer d'une autre manière ? Je ne vois rien dans RFC 5246 pour suggérer cela.

<-- EDIT -->

Voici un patch de mes changements :

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

Answer 1

L'échange de clés du client contiendra :

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

J'ai implémenté TLS en Java et j'ai suivi la même structure et cela fonctionne bien pour moi.

Dois-je signer l'accusé de réception ?

Non il y a pas besoin de signer la valeur publique DH du client il est transféré en texte clair.

Vous pouvez prendre un pcap et vérifier si les mêmes valeurs sont transférées dans le paquet. De plus, si GNU TLS dispose d'un logger pour imprimer les données de la base de données Y_C reçu, alors vous pouvez vérifier si les données correctes sont reçues.

Si vous obtenez toujours un secret pré-master différent, il semble y avoir un problème avec la logique de génération du secret.