1

我正在制作一个 Android 应用程序，其中涉及两部手机在几分钟内交换大量数据。我希望对这种通信进行加密，并且一直在研究各种可用的加密选项。似乎最适合的是混合算法，它使用非对称加密（如 RSA）来交换会话密钥和对称算法（如 AES）来实际加密/解密数据。

根据我对混合加密的了解，两个设备之间发送的每个数据包都应该使用一个新的会话密钥，该密钥嵌入在数据包中（使用对方的公钥加密），以便于另一端的解密。

为了节省 CPU，我正在考虑只使用一个使用 RSA 交换的会话密钥，然后使用此密钥加密/解密所有数据，这样我就可以节省昂贵的 RSA 操作。但是，我知道不建议这样做？有人可以确认一下并告诉我应该如何进行吗？

编辑：

以为我会在这里添加更多信息-

通信协议完全是我自己定制的。数据以未加密的 UDP 数据包形式发送，其中包含大量元数据和加密的有效负载。这样就排除了使用常规 SSL / TLS。

此外，对于每个会话，我都会生成新的私钥和公钥，交换公钥，然后使用它来交换 AES 中使用的会话密钥。我使用的是 2048 位 RSA 和 256 位 AES。AFAIK，这对于大多数交流来说已经绰绰有余，而且可能有点矫枉过正。我承认我的密码学知识并不出色，但我正在尽可能多地阅读和学习以使其尽可能安全。

4

2 回答 2

1

它没有任何“错误”，只是安全性权衡。密钥越长，会话可以越长。您正在尝试使密钥保持足够长的时间，或者会话足够短，或者混合使用，这样密钥妥协在可用的时间内是不可行的。您还需要考虑如果密钥被破解，是否可以泄露整个会话的数据，或者您是否需要每条消息的新密钥的额外安全性等等。

于 2013-09-04T00:06:13.463 回答
0

为什么不使用 al long live TLS/SSL session？这几乎完全符合您的要求，效率很高，并且不需要您编写棘手的加密代码，您几乎肯定会出错。

一般来说，我所知道的几乎所有加密系统都会为整个会话生成一个对称密钥，并在整个会话期间使用它。这就是 TLS 和 SSH 所做的。我相信这就是 IPSEC 所做的。从密码学的角度来看，这没有问题，假设您使用像 AES 这样的理智密码，具有足够大的 IV/计数器/随机数，因此它们不会重复。

使用它的一个担心是，如果您的密钥泄漏，您会丢失会话中的所有数据。但是，如果您的密钥会泄露，那么您的私钥也会泄露。此时攻击者可以解密先前的会话密钥并获取数据，即使您遵循每个数据包一个密钥的模式。

于 2013-09-04T00:18:45.440 回答