From: Kalpesh Parekh <kalpesh.ork2_at_gmail.com>

Date: Wed, 10 Jul 2013 08:40:35 -0700

Date: Wed, 10 Jul 2013 08:40:35 -0700

Made one small change to the logic. Instead of subtracting -1 at step 6 for

RSA and step 4 for DSS, I first converted the values to bits. Then

subtracted the number of leading 0s in the first byte. I needed to do this

because for bit strengths in RSA with values like 1205, 1206, etc, the

above logic returned1208 always. This is because the first byte was always

non-zero and therefore the length was calculated as 1208. I noticed in all

the cases that if I subtract the number of leading zeroes, I would get the

exact length. Can someone please verify the logic? I have been verifying

this against ssh-keygen -l.

The way I am creating the keys on my server is ssh-keygen -b <str> -t rsa.

My passphrase is always empty.

Is there a case I am missing?

On Tue, Jul 9, 2013 at 6:17 AM, Kalpesh Parekh <kalpesh.ork2_at_gmail.com>wrote:

*> This is the logic I have used and tested against a limited set of servers:
*

*> 1) RSA key -
*

*> i) Read the length of identifier
*

*> ii) Skip that many bytes
*

*> iii) Read the length of the exponent
*

*> iv) Skip that many bytes
*

*> v) Read the length of modulus.
*

*> vi) If the first byte of modulus is 0x00 subtract -1 from the length
*

*> of modulus. This is based on the RFC definition of mpint and some examples
*

*> as follows. Example 2 and 3 are noteworthy. The length is 08 and the MSB is
*

*> 0. So no padding with 0x00 was done. But for example 3, the padding was
*

*> done and the length was set to 2.
*

*>
*

*> Examples:
*

*>
*

*> value (hex) representation (hex)
*

*> ----------- --------------------
*

*> 0 00 00 00 00
*

*> 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
*

*> 80 00 00 00 02 00 80
*

*> -1234 00 00 00 02 ed cc
*

*> -deadbeef 00 00 00 05 ff 21 52 41 11
*

*>
*

*> 2) DSA key -
*

*> i) Read the length of identifier
*

*> ii) Skip that many bytes
*

*> iii) Read the length of the modulus
*

*> iv) If the first byte of modulus is 0x00 subtract -1 from the length
*

*> of modulus.
*

*>
*

*> The logic is based off on RFC 4253-page #15 where the DSS key format and
*

*> RSS key formats have been defined. The interpretation of the fields
*

*> p,q,g,y, e and n can be found in RFC 3447, sec 3.1 and FIPS publication
*

*> 186. The commonality is modulus represents (n for RSA and p for DSS) the
*

*> length of the host key in bytes.
*

*>
*

*> Can some one from crypto group confirm if the interpretation is correct?
*

*>
*

*> Alex, I hope I am correct in saying that p,q,g & y form the
*

*> dss_signature_blob and e,n form the rss_signature blob.
*

*>
*

*>
*

*>
*

*>
*

*> On Mon, Jul 8, 2013 at 8:49 AM, Kalpesh Parekh <kalpesh.ork2_at_gmail.com>wrote:
*

*>
*

*>> See this link
*

*>>
*

*>> http://tools.ietf.org/html/rfc4253#page-15
*

*>>
*

*>> Per the link, DSA signature is encoded as follows:
*

*>> string "ssh-dss"
*

*>> string dss_signature_blob
*

*>>
*

*>> RSA signature is encoded as follows:
*

*>> string "ssh-rsa"
*

*>> string rsa_signature_blob
*

*>>
*

*>>
*

*>> On Mon, Jul 8, 2013 at 8:48 AM, Kalpesh Parekh <kalpesh.ork2_at_gmail.com>wrote:
*

*>>
*

*>>> First, apologies for not replying inline to the emails.
*

*>>>
*

*>>> After your suggestions Alex, here is what I could determine.
*

*>>>
*

*>>> I printed out the hex code for the session key for both RSA and DSA
*

*>>> types in my setup.
*

*>>>
*

*>>> Here are the first few bytes:
*

*>>> (RSA) 00 00 00 07 73 73 68 2D 72 73 61 00 00 00 01 23 00 00 00 81
*

*>>>
*

*>>> (DSA) 00 00 00 07 73 73 68 2D 64 73 73 00 00 00 81
*

*>>>
*

*>>> As you mentioned, the first four bytes indicate, the length of the
*

*>>> identifier (7 in this case)
*

*>>> 73 73 68 2D 72 73 61=ssh-rsa
*

*>>> 73 73 68 2D 64 73 73=ssh-dsa
*

*>>>
*

*>>> The next four bytes for RSA indicates some sort of value. In my case it
*

*>>> is #. For DSA, it indicates (length of the key + 1) verified through
*

*>>> ssh-keygen -l command.
*

*>>> For RSA, the last four bytes printed above indicate (length of the key +
*

*>>> 1).
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>> My next target is to decode the signature blobs. I feel like I am close
*

*>>> and can close this if any one can help.
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>>
*

*>>> On Thu, Jul 4, 2013 at 3:07 AM, Kalpesh Parekh <kalpesh.ork2_at_gmail.com>wrote:
*

*>>>
*

*>>>> Thanks Alex,
*

*>>>>
*

*>>>> So far it has been helpful.
*

*>>>>
*

*>>>> So based on the RFC, I understand that the host key received from the
*

*>>>> server has following components
*

*>>>> K_S || f || s
*

*>>>>
*

*>>>> I need to parse the K_S part for RSA key. How do I do that.
*

*>>>>
*

*>>>> Also, how can I implement a generic logic for getting the bit strength
*

*>>>> from the host key.
*

*>>>>
*

*>>>>
*

*>>>
*

*>>>
*

*>>
*

*>
*

_______________________________________________

libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Received on 2013-07-10