Re: [Curdle] Confirming a change to draft-ietf-curdle-rsa-sha2-12

[denis bider <[e-mail]>]

> My read-integer code accepts leading zeroes and strips them,
> based on implementations that assume e.g. a 1024-bit RSA key
> always produces 128 bytes of output

It does. :)


> and memcpy() the result into a zero-filled 128-byte field.

That's actually the correct encoding according to RFC 8017.


>  I also reject anything that's supposed to be signed where
> the sign bit is set:

That's OK, it relates to mpint fields that aren't the RSA signature though.
The RSA signature is a string, not an mpint, and is unsigned.



On Tue, Mar 13, 2018 at 2:01 AM, Peter Gutmann <[e-mail]>
wrote:

> denis bider <[e-mail]> writes:
>
> >What I cannot say is how many implementations might ACCEPT a signed
> encoding
> >if it is sent. If they do, I have no idea how many extra zeros such
> >implementations might accept. It might be that there exist implementations
> >(perhaps including ours!) that will accept an arbitrary number of leading
> >zeros.
>
> My read-integer code accepts leading zeroes and strips them, based on
> implementations that assume e.g. a 1024-bit RSA key always produces 128
> bytes
> of output and memcpy() the result into a zero-filled 128-byte field.  I've
> seen stuff like this in the past, in PGP code I think (the read-integer
> code
> is shared across a range of different crypto protocols).
>
> I also reject anything that's supposed to be signed where the sign bit is
> set:
>
>         /* If we're reading a signed integer then the sign bit can't be set
>            since this would produce a negative value.  This differs from
> the
>            ASN.1 code, where the incorrect setting of the sign bit is so
> common
>            that we always treat integers as unsigned */
>
> Peter.
>