我正在制作一个Android应用程序，它涉及两部手机在几分钟内交换大量数据。我希望这种通信能够加密，并且一直在研究各种可用的加密选项。似乎最合适的是混合算法，它使用非对称加密（如RSA）来交换会话密钥和对称算法（如AES）来实际加密/解密数据。
根据我所知的混合加密，两个设备之间发送的每个数据包都应该使用一个新的会话密钥，该密钥嵌入在数据包中（用另一方的公钥加密），以便在另一端进行解密。
为了节省CPU，我考虑只使用一个使用RSA交换的会话密钥，然后使用此密钥加密/解密所有数据，这样我就可以节省昂贵的RSA操作。但是，据我所知，这是不推荐的？有人可以确认一下并告诉我应该怎么办？
修改
以为我会在这里添加更多信息 -
通信协议完全是自定义的，也是我自己的。数据以未加密的UDP数据包发送，包含大量元数据和加密的有效负载。因此规则使用常规SSL / TLS。
此外，对于每个会话，我生成新的私钥和公钥，交换公钥然后使用它来交换AES中使用的会话密钥。我使用的是2048位RSA和256位AES。这个，AFAIK，绰绰有余，可能对大多数通信来说都是过度杀伤力。我承认我对密码学的了解不是很好，但我正在尽可能多地阅读和学习，以使其尽可能安全。
答案 0 :(得分：1)
没有任何'错误'，只是一个安全权衡。密钥越长，会话就越长。你试图保持密钥足够长，或者会话足够短，或者混合使用，这样在可用时间内密钥泄露是不可行的。如果密钥被破解，或者您是否需要为每条消息或其他任何内容提供额外的新密钥安全性，还需要考虑是否可以泄漏整个会话的数据。
答案 1 :(得分：0)
为什么不使用长时间的TLS / SSL会话？这几乎完全符合您的要求，并且不需要您编写棘手的加密代码，几乎肯定会出错。
通常，我所知道的几乎所有加密系统都会为整个会话生成一个对称密钥，并在此期间使用该密钥。这就是TLS所做的以及SSH的作用。我相信这就是IPSEC所做的。从加密的角度来看，这是没有问题的，假设您使用像AES这样的理智密码具有足够大的IV /计数器/随机数，使得它们不会重复。
担心使用此问题的方法是，如果您的密钥泄露，则会丢失会话中的所有数据。但是，如果您的密钥可能泄漏，您的私钥也可能泄漏。此时，即使您按照每个数据包模式使用一个密钥，攻击者也可以解密以前的会话密钥并获取数据。