42

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

Community
  • 1
  • 1
jawr
  • 827
  • 1
  • 7
  • 14
  • 1
    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. – Jumbogram Sep 14 '12 at 15:08
  • @Jumbogram it can be a bit tricky to find out how though, but it certainly parses SSL all right. – Maarten Bodewes Sep 14 '12 at 18:06
  • @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. – Jumbogram Sep 15 '12 at 10:11
  • 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. – jawr Sep 17 '12 at 14:21
  • Try to output numbers before sending and after receiving. I think you have a transmission problems. – Pavel Ognev Sep 18 '12 at 06:02
  • 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. – jawr Sep 18 '12 at 08:56
  • 1
    Can you show us some code? I have a feeling this will be a "many eyes" problem. – Intermernet Jun 27 '13 at 14:50
  • 1
    Yeah, it would really help if you could make an SSCCE: http://sscce.org/ – David Grayson Jun 30 '13 at 01:12
  • 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. – Shog9 Jul 08 '13 at 09:49
  • 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? – Luke Jul 15 '13 at 15:13
  • 1
    Are you sure you're using a Primitive Root modulo N as G?http://en.wikipedia.org/wiki/Primitive_root_modulo_n – Tizianoreica Feb 17 '14 at 08:36
  • 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. – jawr Mar 06 '14 at 12:01
  • Added the patch to the question. – jawr Mar 06 '14 at 12:05

1 Answers1

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.

Narendra Pathai
  • 41,187
  • 18
  • 82
  • 120