Wade L. Scholine wrote: ... > > The typical error message in case of PKCS#1 error (in your case) would > > be "RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE". > > I'm not clear on the difference between these. The modulus is n, the > product of the primes p and q that are used for key generation, right? I > was under the impression that modulus length == key size. Not so?
Of course you are right, but the PKCS#1 padding would trigger the "RSA_R_DATA_TOO_LARGE_FOR_KEY_SIZE" error message => RSA_eay_private_encrypt() does not use PKCS#1 in your case padding. The "RSA_R_DATA_TOO_LARGE_FOR_MODULUS" error simply means that your modulus is too small (even without padding). > > Would a good approach be perhaps to generate keys until I found one for > which n is greater than the bignum representation of the largest plaintext? > (Yeah, I know, this would restrict the key space, which might be a security > concern.) It would be sufficient is the highest bit of the plaintext is zero , because the highest bit of the modulus is certainly set (at least if the key is generated with OpenSSL). ... > > it should work (, but what about a longer (== more secure) key ?) > > For reasons that would be tedious to rehearse, the size of the encrypted > block has to be not more than 15 octets. > > I was hoping for something a little more definitive than "should work." Ok , unless something really strange happens: it will work :-) Regards, Nils ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]