www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: SSH2 host key length and hash compute

Re: SSH2 host key length and hash compute

From: Alexander Lamaison <swish_at_lammy.co.uk>
Date: Mon, 8 Jul 2013 23:59:46 +0100

On 8 July 2013 16:48, 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
> #.

That value is the RSA public exponent field 'e' (see [1]) in SSH
'mpint' form (see [2]). The cheeky thing about the way RFC 4251
defines mpint is that it says it is a two's complement integer *stored
as a string*. In other words it has a length-prefix, so your exponent
is a 1 byte two's-complement integer 35 (hex 23).

> 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).

For DSA the next field is the public prime number 'p', again,
length-prefixed. This is the field of the DSA key that indicates it's
strength (at least that's how ssh-keygen -l calculates it). I'm
guessing the length is one byte more than expected because of the
following from the mpint definition:

"If the most significant bit would be set for a positive number, the
number MUST be preceded by a zero byte."

So the strength of the key is actually the number of significant bits
in the 'p' field, rather than the length in the string prefix, which
is reassuringly similar to how ssh-keygen calculates it by passing the
field to BN_num_bits.

Similarly for the RSA key, except that the next field is the public modulus 'n'.

> 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

These are *signatures* rather than keys. I don't know exactly where
they fit in, but they don't seem to apply here.

Usual caveat: I've just worked this lot out from reading the RFCs etc,
so you should really check it with someone better versed in crypto.

[1] http://tools.ietf.org/html/rfc4253#page-15
[2] http://tools.ietf.org/html/rfc4251#page-9

Alex

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2013-07-09

the libssh2 team