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-09