Pre-master secret mistmatched when implementing Diffie-Hellman key exchange

Question

I am trying to implement DHE_DSS into go's crypto/tls package. Unfortunately I can not seem to get the PreMasterSecret (Z) to be the same, my basic workflow is:

Receive Server Key Exchange Message

• Extract P, G, Ys
• Verify using the digital signature provided

Prepare Client Key Exchange Message

• Create client's Xc
• Generate Yc (Yc = G^Xc % P)
• Generate Z (Z = Ys^Xc % P)
• Send back Yc, packed like so:

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

However, when I am debugging this with gnutls-serv the two PreMasterSecrets (Z) are different. Do I need to sign the returned Yc, or perhaps pack it in another way? I can not see anything in RFC 5246 to suggest this.

<-- EDIT -->

Here is a patch of my changes:

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

Unsociable

As a heads-up, recent versions of wireshark (1.8 and later) will parse the Client and Server key exchange messages, which should help in debugging. – Mesarch

@Mesarch it can be a bit tricky to find out how though, but it certainly parses SSL all right. – Capuchin

@jawr: everything you have above looks right, I'd suggesting doing a capture to make sure the packet format is right; then double-checking the arithmetic with python. – Mesarch

Unfortunately been side tracked from this. I will try and catch the packet(s) to see if if that gives me any answers. Thankyou for the responses. – Unsociable

Try to output numbers before sending and after receiving. I think you have a transmission problems. – Yonyona

Well with gnutls-serv I can't get it to print it's Y before transmitting, otherwise this would be quite useful for debugging. I wonder if it's being marshalled incorrectly. – Unsociable

Can you show us some code? I have a feeling this will be a "many eyes" problem. – Broad

Yeah, it would really help if you could make an SSCCE: sscce.org – Atkins

BTW, @Micha: when possible, try to improve titles beyond just removing tags; unless the title is already very long, you should strive to give casual readers enough information between the title and tags to decide whether or not to click through and read further. – Rosetterosewall

Can you point out where in the RFC how you got Xc and Yc? Perhaps you could provide code of each of the steps? Something that can be re-produced in play.golang.org? – Pytlik

Are you sure you're using a Primitive Root modulo N as G?en.wikipedia.org/wiki/Primitive_root_modulo_n – Ingold

I had dropped this and instead used an openssl wrapper. I'm pretty certain I had not used a Primitive root modulo though, I will try dig up the code to see if I can get it working with your suggestion. I do not remember reading it in the RFC though. – Unsociable

Added the patch to the question. – Unsociable

Answer 1

Client key exchange will contain:

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

I have implemented TLS in Java and I follow the same structure and works fine for me.

Do I need to sign the returned Yc?

No there is no need to sign the client DH public value, it is transferred in plain text.

You can take a pcap and check whether same values are being transferred in the packet. Also if GNU TLS has logger for printing the Y_C received, then you can check if proper data is being received.

If in case you still getting different Pre-Master secret then there seems to be some issue with the logic of generation of secret.

Betthel