Typically it is recommended that RSA be used to encrypt a symmetric key, which is then used to encrypt the "payload".
What is the practical (or theoretical) limit to the amount of data that can be encrypted with RSA (I'm using a 2048 bit RSA keysize).
In particular, I'm wondering if it is safe to encrypt an RSA public key (256 bytes) with a (different) RSA public key? I'm using the Bouncy Castle crypto libraries in Java.
For a n-bit RSA key, direct encryption (with PKCS#1 "old-style" padding) works for arbitrary binary messages up to floor(n/8) - 11 bytes. In other words, for a 1024-bit RSA key (128 bytes), up to 117 bytes.
With OAEP (the PKCS#1 "new-style" padding), this is a bit less. OAEP uses a hash function with output length h bits; this implies a size limit of floor(n/8) - 2*ceil(h/8) - 2. For a 1024-bit RSA key using SHA-256 as the hash function (h = 256), this means binary messages up to 62 bytes.
There is no problem in encrypting a RSA key with another RSA key (there is no problem in encrypting any sequence of bytes with RSA, whatever those bytes represent), but, of course, the "outer" RSA key will have to be bigger: with old-style padding, to encrypt a 256-byte message, you will need a RSA key with a modulus of at least 2136 bits.
Hybrid modes (you encrypt data with a random symmetric key and encrypt that symmetric key with RSA) are nonetheless recommended as a general case, if only because they do not have any practical size limits, and also because they make it easier to replace the RSA part with another key exchange algorithm (e.g. Diffie-Hellman).
The limit is more or less infinite, but as you say yourself, this is not how asymmetric crypto should be used. The methods used to implement an asymmetrical crypto system are orders of magnitude slower than those for symmetric crypto (such as AES, TrippleDES, PRESENT, ...). So why would you do that? Use your asymmetric crypto to establish a key (using a secure key establishment protocol, don't invent one) and then encrypt your data with a symmetric algorithm using the established key.
On an related note: why would you encrypt with another public key? As the name says, it's supposed to be public. An attacker can't do anything with it if he gets his hands on it.
[Edit] One thing you should definitely check is if the functions you use implement padding (preferably RSAES-OAEP). Otherwise your public key will encrypt to the same output every time and thus an adversary spying in on your communication can still learn that it is you who is transmitting something, even though he can't see which public key it is you are transmitting.
The (theoretical) limit is infinite.
For the practical limit, you'll have to make tests with your particular hardware/software implementation and compare to your requirements regarding speed.
Regarding safety, I'd say yes. Your identity (that you want hidden) is as safe as your recipient's private key's safety.
Three years after you asked the question, I stumbled across your posting, because I just had to implement something similiar. What you will need in this case is an encryption mode to break the message into key sized chunks, because of the maximum message length. You will also need block padding to pad each block of the message (oposed to message padding that is usually applied to something like DES,3DES,AES). Not easy, but possible. You need to make sure that each padded block is smaller than the maximum allowed size. For block padding you could use for example OAEP or PKCS_V1_5. As encryption mode you could use ECB (not secure but works) or something more elaborated. (see wikipedia and encryption modes).
if you have a good crypto API you should be able to set the encryption mode and block/message padding and just throw the message at it.
