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