Re: Problems with draft

[Markus Friedl <markus%openbsd.org@localhost>]

On Sat, Nov 29, 2003 at 05:40:25AM -0500, der Mouse wrote:
> In transport-17, section 6.2 writes of a "shared secret K", treating it
> as an opaque blob which is passed as part of a HASH argument.  But
> section 7 writes of K as a large integer.  It's not entirely clear how
> the one is converted into the other; looking at existing code, I find
> that the kex code treates it as a large integer (which will need fixing

from the draft (section 6.2)

   ...
   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data."A" means the single character A, ASCII 65).
   ...

So I don't think the core drafts need to changed at this point.

> if-and-when key exchange methods that produce a K that's not
> conceptually a large integer, though that's an implementation matter
> rather than a spec matter), but when serializing it for hashing it uses
> the same code it uses for "mpint" serialization.  I would like to see
> the draft clearly state exactly how the large integer K of section 7 is
> converted into the opaque blob K of section 6.2.  The description of
> H's computation seems to imply that this should be done as the code
> does it, but it's not clearly stated.
> 
> Also, section 7 writes
> 
>    The hash H is computed as the HASH hash of the concatenation of the
>    following:
> [...]
>      string    I_C, the payload of the client's SSH_MSG_KEXINIT
>      string    I_S, the payload of the server's SSH_MSG_KEXINIT
> [...]
> 
> It is not clear whether these are compressed or uncompressed; while
> this doesn't matter for the first key exchange, it matters for
> re-exchange, and I'd like to see the draft state it clearly.

It refers to the payload after the transport layer transformations,
i.e. after decryption and decompression, with padding removed.

Again, I don't think a change in the core drafts is necessary.

> transport-17 section 5.6 says
> 
>    The "ssh-rsa" key format has the following specific encoding:
> [...]
>    Signing and verifying using this key format is done according to
>    [SCHNEIER] and [PKCS1] using the SHA-1 hash.
> 
> I have been unable to find any description of a signature algorithm for
> RSA in Schneier, and I have found no reference anywhere to explain what
> [PKCS1] is supposed to refer to - I assume this is as described in
> RFC2437?

Yes, it seems the reference is missing. AFAIK it refers to
section 8.2 from RFC 3447.

-m