分解大数据以进行 RSA 加密
最近，我们一直在深入研究使用 OpenSSL 来帮助加密/解密我们拥有的一些数据。每个“客户端”都将拥有本地证书颁发机构向他们提供的公钥/私钥对和 X509 证书。我现在正在研究使用该密钥对加密/解密数据。
我研究过的所有内容都显示使用 RSA_public_crypt 和 RSA_private_decrypt 方法进行 RSA 加密。但对于填充类型 RSA_PKCS1_OAEP_PADDING，我一次可以加密的数据量受到 RSA_size(rsa) - 41 的限制。所以我的问题是如何在坚持我们的 RSA 方案（无静态密钥短语等）的同时加密大量数据。我正在考虑将数据分解成块，然后对其进行加密，但这似乎违背了填充的目的。
任何帮助将不胜感激。
Recently we've been diving into using OpenSSL to help encrypt/decrypt some data we have. Each "client" will have Public/Private key pair and X509 Certificate given to them by a local Certificate Authority. I'm now looking into encrypting/decrypting data with that key pair.
Everything I've looked into show using the methods RSA_public_encrypt and RSA_private_decrypt for RSA encryption. But the amount of data I can encrypt at once is limited by RSA_size(rsa) - 41 for the padding type RSA_PKCS1_OAEP_PADDING. So my question is how to encrypt larger amounts of data while sticking to our RSA scheme (no static keyphrases, etc). I was thinking about breaking the data up into chunks and then encrypting it but that seems like it's defeating the point of padding.
Any help would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
即使你破坏了数据，你也会发现，速度慢得惊人。正确的方法是
Even if you break the data, you will find out, that the speed is prohibitively slow. The right method is
您应该使用 CMS（电子邮件客户端中 S/MIME 支持的基础）或 PGP 等标准。几乎每个平台都有适用于这两个标准的库。
您会发现它们的批量数据加密方法非常相似，使用对称密码来加密数据并使用“消息”接收者的公钥来加密该秘密密钥。这种方法安全且快速。
然而，这些标准更进一步，安全地处理您可能还没有想到的事情，例如加密多个收件人的数据、将元数据附加到加密内容等。您还可以获得与其他软件的互操作性。例如，如果您使用 S/MIME，则可以使用任何平台上的几乎任何电子邮件客户端来解密。事实上，根据您的集成要求，您可能不需要自己编写任何软件。
使用这些成熟的协议之一并不能解决所有的安全问题，但它会使做一些真正愚蠢的事情变得更加困难。
You should use a standard like CMS (the basis of the S/MIME support in your email client) or PGP. There are libraries for both of these standards for just about every platform.
You will find that they are very similar in their approach to bulk data encryption, using a symmetric cipher to encrypt data and encrypting that secret key with the public key of the "message" recipients. This approach is secure and fast.
However, these standards go further, securely handling things you might not have thought about yet, like encrypting the data for multiple recipients, attaching meta-data to the encrypted content, etc. You also get interoperability with other software. For example, if you use S/MIME, you can use just about any email client on any platform to decrypt. In fact, depending on your integration requirements, you might not need to write any software yourself.
Using one of these well-established protocols won't solve all of your security problems, but it will make it more difficult to do something really dumb.