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

[Ben Harris <bjh21%bjh21.me.uk@localhost>]

In article <200504031131.HAA21102%Sparkle.Rodents.Montreal.QC.CA@localhost> you 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.
>
>> 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.

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