我有一些内容（“消息”），我需要始终能够加密（发送时）。它只能由接收方解密。最初，我有一个简单的结构，其中使用公共密钥对消息进行加密，然后接收者使用其私有密钥对所有消息进行解密。但是，由于我使用的是RSA，因此我无法真正轻松地发送更大的消息。
我正在想象两个潜在的解决方案，但不确定如何实现更好的解决方案。
（（Easy）只是将每条消息分成许多较小的部分，对其进行加密和存储。这只会更改我的应用程序的查询结构，而不会更改编码内容。
我可以使用对称密钥对消息进行加密，这更快并且可以在任何大小上使用。但是，我将需要使用非对称密钥来加密该对称密钥。问题是，只有在提供非对称私有密钥时，即当接收者想要读取其消息时，我才可以解密对称密钥。因此，在那种情况下，我将如何实际加密消息？由于我不希望发送者也能够访问用于解密的密钥。
然后问题就来了，我只能在提供非对称私有密钥时（即，接收者想要读取其消息时，才能解密对称密钥）。因此，在那种情况下，我将如何实际加密消息？
很简单，您使用临时的，特定于消息的对称密钥进行数据加密之前，并使用公共密钥对其进行加密。最好在此之后明确销毁对称密钥。您可以在消息的密文之前添加包装（加密）的对称密钥，因为它的字节大小总是与模数相同（即RSA密钥大小以字节为单位）。
您正在考虑的系统称为混合密码系统，它比为RSA拆分消息要好得多。还有其他多种方法可以完成相同的任务，例如RSA-KEM和-对于椭圆曲线-ECIES。但是，两者都不经常出现在加密图书馆中。
如果您决定将RSA / AES用于发送密码，那么我建议您使用OAEP，例如AES-CTR而非AES-CBC，因为RSA PKCS＃1 v1.5填充和CBC填充都容易受到填充oracle攻击。
强烈建议对消息进行签名，否则对手可以加密假消息。加密仅用于实现消息的机密性，而不用于实现消息的完整性和真实性。如果可以发送任何消息，对手甚至可以尝试纯文本oracle攻击。如果您不允许一组您控制的私钥，那么您应该签名然后加密，而不是签名然后加密。
并且一如既往，如果这是传输安全性的一种选择，则首选TLS或其他显式安全传输协议。