Subject: draft-harris-ssh-rsa-kex-01.txt

From: der Mouse <[email-masked]>
Date: Sat, 2 Apr 2005 20:16:10 -0500 (EST)

I've just been trying to implement draft-harris-ssh-rsa-kex-01.txt.
There is a subtle gotcha lurking in that spec that I would like to see
clarified.

One of the packets is described as

       byte      SSH_MSG_KEXRSA_SECRET
       string    RSAES-OAEP-ENCRYPT(K_T, K)

Now, the OAEP encryption is a raw RSA encryption of a number computed
in a complicated way that's not relevant here.  Thus, it is,
fundamentally, a big number, even though 3447 specifies that it's
converted to an octet string.

Now, RFC3447 *does* specify that conversion.  But the encoding of this
data blob as a string is deceptively close to the encoding of the big
number as an mpint (the major difference is exactly how and when
leading zero bits are included).  I'd like to see this similarly
explicitly acknowledged and clarified.  Maybe something like

   Note that the encoding of the encrypted secret is similar to the
   "mpint" encoding of the raw RSA encryption result, but differs in
   its handling of high-order 0 bits.  The packet contains the octet
   sequence as a "string", not the raw RSA output as an "mpint".

(Assuming of course that that's what is intended; if not, the wording
needs even mroe work.)

Thoughts?  Comments?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 03 Apr 2005 20:53:11 +1200

der Mouse <[email-masked]> squeeked:

>Now, RFC3447 *does* specify that conversion.  But the encoding of this data
>blob as a string is deceptively close to the encoding of the big number as an
>mpint (the major difference is exactly how and when leading zero bits are
>included).  I'd like to see this similarly explicitly acknowledged and
>clarified.

Why is it encoded as a string in the first place when the value is quite
clearly an integer?  For the equivalent DH keyex, the corresponding quantities
e and f are encoded as mpints and not strings.  Making a subtle change to the
encoding for this alternative keyex method seems to be asking for implementor
confusion.

Peter.

---

From: der Mouse <[email-masked]>
Date: Sun, 3 Apr 2005 07:24:48 -0400 (EDT)

>> Now, RFC3447 *does* specify that conversion.  But the encoding of
>> this data blob as a string is deceptively close to the encoding of
>> the big number as an mpint (the major difference is exactly how and
>> when leading zero bits are included).  I'd like to see this
>> similarly explicitly acknowledged and clarified.

> Why is it encoded as a string in the first place when the value is
> quite clearly an integer?

I don't know, of course, since I didn't design it - but I suspect it
was done in order to directly use the existing RSAES-OAEP mode from
RFC3447 (or perhaps I should be saying PKCS #1, but 3447 is the
reference I used), as the existing definition is octet-string ->
octet-string encryption.

> For the equivalent DH keyex, the corresponding quantities e and f are
> encoded as mpints and not strings.  Making a subtle change to the
> encoding for this alternative keyex method seems to be asking for
> implementor confusion.

Yes.  But I can understand a desire to use an existing spec directly,
rather than making slight changes to it.  Encoding that as an mpint
instead of a string would require draft-harris-ssh-rsa-kex to go under
the hood of RFC3447 (or else specify converting it back from an octet
string to a big number, which is almost uglier).  If you have existing
RSAES-OAEP library code, you can use it directly with the current spec.

That's why I suggested emphasizing that it's a string rather than an
mpint, as opposed to suggesting switching from opaque-blob-as-string to
big-number-as-mpint.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Ben Harris <[email-masked]>
Date: Sun, 03 Apr 2005 14:11:32 +0100

>(Assuming of course that that's what is intended; if not, the wording

That is the intention, yes, and I agree that it would probably be best to
make this difference explicit.  Your text seems good to me.  Secsh-transport
has a similar problem with the output of RSASSA-PKCS1-v1_5-SIGN, which is
similarly an I2OSP-encoded integer.  For comparison, the text there is:

   The value for 'rsa_signature_blob' is encoded as a string containing
   s (which is an integer, without lengths or padding, unsigned and in
   network byte order).

I think yours is better, since it still defers to PKCS#1.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Sun, 03 Apr 2005 14:22:04 +0100

>reference I used), as the existing definition is octet-string ->

That's precisely it. I wanted to be able to treat RSAES-OEAP as a black box
that operated on octet-strings.  This seemed reasonable since it's precisely
how secsh-transport handles RSASSA-PKCS1-v1_5, which similarly emits an
I2OSP-encoded integer as the signature, which then gets wrapped up in an SSH
"string" when used as an ssh-rsa signature.

>If you have existing RSAES-OAEP library code, you can use it directly with
>the current spec.

This was another consideration.  My first implementation was in OpenSSH,
which could just use OpenSSL's existing OAEP code without having to jump
through hoops to change the encoding.

-- 
Ben Harris

---

From: [email-masked] (Niels Möller)
Date: 05 Apr 2005 16:09:38 +0200

[ This is a repost, by mistake I first replied only to Ben Harris, not
  to the list. ]

Ben Harris <[email-masked]> writes:

> make this difference explicit.

I don't quite like the old choice of the "string" type for
rsa_signature_blob (and dss_signature_blob) instead of mpint, although
I understand it may make the interface to off-the-shelf RSA libraries
a little easier.

At a first look, it seems like you're introducing yet another
almost-mpint representation for one particular bignum in the protocol,
which at least to me appears as a very bad idea; my gut reaction was
the same as Peter's.

If you want to do it this way, it's easier to accept if you make clear
that you're really using the same representation as for
rsa_signature_blob (at least I hope you *are* using the same
representation, but I haven't looked into this in sufficient detail
yet).

Regards,
/Niels

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Apr 2005 14:04:50 -0400

>>>>> "Ben" == Ben Harris <[email-masked]> writes:

    Ben> In article
    Ben> <[email-masked]> you
    Ben> write:
    >> Now, RFC3447 *does* specify that conversion.  But the encoding
    >> of this data blob as a string is deceptively close to the
    >> encoding of the big number as an mpint (the major difference is
    >> exactly how and when leading zero bits are included).  I'd like
    >> to see this similarly explicitly acknowledged and clarified.
    >> Maybe something like
    >> 
    >> Note that the encoding of the encrypted secret is similar to
    >> the "mpint" encoding of the raw RSA encryption result, but
    >> differs in its handling of high-order 0 bits.  The packet
    >> contains the octet sequence as a "string", not the raw RSA
    >> output as an "mpint".
    >> 
    >> (Assuming of course that that's what is intended; if not, the
    >> wording needs even mroe work.)

    Ben> That is the intention, yes, and I agree that it would
    Ben> probably be best to make this difference explicit.  Your text
    Ben> seems good to me.  Secsh-transport has a similar problem with
    Ben> the output of RSASSA-PKCS1-v1_5-SIGN, which is similarly an
    Ben> I2OSP-encoded integer.  For comparison, the text there is:

I'm a strong proponent of reuse of primitives and of other
specifications where appropriate.  Personally, I believe your decision
is correct.

--Sam