使用 RSA 加密的数据量有什么限制？
通常，建议使用 RSA 来加密对称密钥，然后使用对称密钥来加密“有效负载”。
可以使用 RSA 加密的数据量的实际（或理论）限制是多少（我使用的是 2048 位 RSA 密钥大小）。
特别是，我想知道使用（不同的）RSA 公钥加密 RSA 公钥（256 字节）是否安全？我正在使用 Java 中的 Bouncy Castle 加密库。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
对于 n 位 RSA 密钥，直接加密（使用 PKCS#1“旧式”填充）适用于最多
floor(n/8) - 11字节的任意二进制消息。换句话说，对于 1024 位 RSA 密钥（128 字节），最多为 117 字节。对于 OAEP（PKCS#1“新式”填充），这会少一些。 OAEP 使用输出长度为 h 位的哈希函数；这意味着大小限制为
floor(n/8) - 2*ceil(h/8) - 2。对于使用 SHA-256 作为哈希函数 (h = 256) 的 1024 位 RSA 密钥，这意味着最多 62 字节的二进制消息。使用另一个 RSA 密钥加密一个 RSA 密钥没有问题（使用 RSA 加密任何字节序列都没有问题，无论这些字节代表什么），但是，当然，“外部”RSA密钥必须更大：使用旧式填充，要加密 256 字节消息，您将需要模数至少为 2136 位的 RSA 密钥。
尽管如此，混合模式（使用随机对称密钥加密数据并使用 RSA 加密该对称密钥）仍然有效推荐作为一般情况，因为它们没有任何实际的大小限制，而且还因为它们使用另一种密钥交换算法（例如 Diffie-Hellman）替换 RSA 部分变得更容易。
For a n-bit RSA key, direct encryption (with PKCS#1 "old-style" padding) works for arbitrary binary messages up to
floor(n/8) - 11bytes. 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).
该限制或多或少是无限的，但正如您自己所说，这不是应该使用非对称加密的方式。用于实现非对称加密系统的方法比对称加密系统的方法（例如 AES、TripleDES、PRESENT 等）慢几个数量级。那你为什么要这么做呢？使用非对称加密来建立密钥（使用安全密钥建立协议，不要发明一个），然后使用所建立的密钥通过对称算法加密您的数据。
相关说明：为什么要使用另一个公钥加密？顾名思义，它应该是公开的。如果攻击者得到了它，他就无法对它做任何事情。
[编辑] 您绝对应该检查的一件事是您使用的函数是否实现了填充（最好是 RSAES-OAEP）。否则，您的公钥每次都会加密为相同的输出，因此监视您的通信的对手仍然可以知道是您在传输某些内容，即使他看不到您正在传输的公钥。
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.
在你问这个问题三年后，我偶然发现了你的帖子，因为我只需要实现类似的东西。在这种情况下，由于存在最大消息长度，您需要一种加密模式来将消息分解为密钥大小的块。您还需要块填充来填充消息的每个块（与通常应用于 DES、3DES、AES 等内容的消息填充相反）。不容易，但有可能。您需要确保每个填充块都小于允许的最大大小。对于块填充，您可以使用例如 OAEP 或 PKCS_V1_5。作为加密模式，您可以使用 ECB（不安全，但有效）或更复杂的东西。 （参见维基百科和加密模式）。
如果你有一个好的加密 API，你应该能够设置加密模式和块/消息填充，然后将消息扔给它。
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.