> Actually, there are only security implications if the input size is so > small that M^e < kn (M is the message, e is the public exponent, n is > the modulus, and k is a small factor - probably less than five). For
Right, but this is the caller's problem. It's why other padding schemes exist and why, presumably, NO_PADDING exists too (ie. to let them get directly to raw RSA). > Why not steal a page from Microsoft's playbook, and have a parallel > API? Call the function RSA_public_encrypt_ext, and have it take an > explicit input AND output buffer length. This function would be pretty > much the same as the existing RSA_public_encrypt function, and the > original function could be eventually implement in terms of the new > one, so the support burden wouldn't be that big. Well we already have plenty of _ex functions of this nature, but as Richard pointed out (correcting my stupidity in the process) the current prototypes are probably ok after all because the single "length" parameter is for the input. 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]
