On March 25, 2004 11:20 am, Richard Levitte - VMS Whacker wrote:
> geoff> On March 25, 2004 10:44 am, Richard Levitte - VMS Whacker wrote:
> geoff> > To begin with, I think the correct interpretation is that the
> output geoff> > buffer is required to have the same size as the
> modulus, so logically, geoff> > an output size parameter isn't required
> except for checking purposes. geoff>
> geoff> Well yes, my point had been that the output size is the only
> size geoff> parameter in the prototype. That's perhaps indicative of
> the state of geoff> affaires. :-)
>
> Uhmm, say what? Currently, the only size parameter is the input size
> (flen). We're still talking about the RSA_{public,private}_encrypt()
> functions, right?
Oh bollox, I'd had it in my mind that the parameter in the API was the
output length. You're more than welcome to slap me at this point.
> geoff> > I guess that allowing an input size that's smaller than the
> modulus geoff> > size could be doable, but isn't adviceable for
> security reasons or geoff> > something like that...
> geoff>
> geoff> Well it could all be handled relative to the padding
> geoff> parameters, the issue again is that the API isn't exposed in
> geoff> this form and changing it involves ... well, you know very well
> geoff> what that involves. <shudder>
>
> Actually, I don't, but give me some time to re-read the thread, 'cause
> I've obviously missed something...
Well that was my oversight, you may be right. I guess the possibility this
opens is that you could adjust the code to tolerate smaller input length
values. The current assumption is that the output buffer's size is the
same as the input, but a better (and I think backwards compatible)
assumption would be that the output buffer is the same size as the
modulus and the input is free to be whatever length it wants. Another
backwards compatible change would be to relax RSA_NO_PADDING to tolerate
short inputs. This would then allow an application to send it arbitrary
numeric input provided it's less than 'n' - because the normal conversion
of input to numeric is to treat the byte string as big-endian numeric
representation anyway.
But personally, I'm not keen to get too deep into thinking this through
nor implementing, I've got enough on my plate with the BIGNUM stuff and
some apache/shmcb hassles ...
> geoff> I think this is just one of those things that doesn't warrant
> geoff> us messing with it right now - if someone cares enough, they
> geoff> could clarify the relevant docs.
>
> I've already made a small change that explains what's expected when
> RSA_NO_PADDING is used...
Yeah, good idea.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
