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