CODEWITHSUNDEEP
sshdigital-signature
Networker25
Networker25

Reputation: 21

computing the exchange hash for ecdsa-sha2-nistp256

I am writing code for an SSH server and can not get past the Elliptic Curve Diffie-Hellman Key Exchange Reply part of the connection. The client also closes the connection and says "Host Key does not match the signature supplied".

I am using putty as the client and a PIC micro-controller is running the server code.

From RFC 5656 [SSH ECC Algorithm Integration] :

"The hash H is formed by applying the algorithm HASH on a concatenation of the following:

  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

"

the host key algorithm and key exchange algorithm is ecdsa-sha2-nistp256 and ecdh-sha2-nistp256 respectively.

referring to RFC 4251 for data type representations, as well as the source code in openSHH (openBSD) this is what I have concatenated.

  1. 4 bytes for then length of V_C followed by V_C
  2. 4 bytes for then length of V_S followed by V_S
  3. 4 bytes for length of I_C followed by I_C (payload is from Message Code to the start of Random Padding)
  4. 4 bytes for length of I_S followed by I_S (payload is from Message Code to the start of Random Padding)
  5. 4 bytes for the length of K_S followed by K_S (for K_S I used the same group of bytes that is used to calculate the fingerprint)
  6. 4 bytes for the length of Q_C followed by Q_C (i used the uncompressed string which has length of 65 - 04||X-coordinate||Y-coordinate)
  7. 4 bytes for the length of Q_S followed by Q_S
  8. 4 bytes for the length of K followed by K (length is 32 or 33 depending is the leading bit is set or not. If it is set then K is preceded by a 00 byte)

Once concatenated I hash it with SHA256 because I'm using NISTP256. SHA256 outputs 32 bytes which is the size of the curve, so I take the whole SHA256 output and perform the signature algorithm on it.

I can never get the correct signature from my message concatenation.

I know my signature algorithm is correct because given the message hash output I can get the correct signature. I know my shared secret is correct because I get the same output as online shared secret calculators. I know the SHA256 is correct because I get the same result using online calculators.

This leads me to assume the error is in the concatenation of the exchange hash.

Any help is greatly appreciated, thanks.

Upvotes: 2

Views: 1095

Answers (1)

Maarten Bodewes
Maarten Bodewes

Reputation: 93948

ECDSA signature generation is non-deterministic, i.e. part of the input is the hash and part of the input consists of random bytes. So whatever you do, you will always get a different signature. This is all right because signature verification will still work.

The only way to get a repeated signature is to mess with the random number generator (during testing, you don't want to sign two values using the same random number: you'd expose the private key!).

Upvotes: 1

Related Questions