On March 24, 2004 03:43 am, Nils Larsch wrote: > > Like the other padding modes, RSA_NO_PADDING is handled by a > > pre-processor, RSA_padding_add_none(), which insists that input and > > output byte buffers have the same length, and the way this is invoked > > from the RSA implementation in rsa_eay.c equates the output buffer > > length (which is not supplied as a parameter in the API) with the > > number of bytes of the RSA modulus. This is the real problem. > > > > The limitation, in other words, is the API :-) I would actually agree > > that RSA_NO_PADDING is counter-intuitive, it really means > > RSA_ALREADY_PADDED. > > That's a matter of how you interpret the meaning of this flag. > My interpretion of the flag is that this flag describes what should > be done with the input. RSA_NO_PADDING means "don't prepend any > padding" whereas , for example, RSA_PKCS1_PADDING means "please prepend > the usual pkcs1 padding". Following this interpretion I don't think the > name is counter-intuitive.
Well I was meaning counter-intuitive at the nit-picking level more than anything warranting CVS action. To my mind, they *both* RSA_NO_PADDING and RSA_ALREADY_PADDED mean "don't prepend any padding", but only one of them means "because I've already ensured the required conditions are met". But other readings are possible (and clearly, RSA_NO_PADDING has survived this far for the simple reason that nobody has seen anything to justify meddling with it). 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]
