我正在创建一个 Android 应用程序,首先需要能够将数据安全地传输到服务器。所以我想到了RSA。
我会将公钥发送给用户,让他做他必须做的事情,然后通过私人接收并解密。没关系。
但现在看来,另一方也应该有某种加密。意思是,应该有加密消息并将其发送给用户的方法,并且只允许特定用户能够阅读它。
这闻起来就像拥有 2 对密钥,并将一对中的公钥和另一对中的私钥发送给用户,并将其余的保留给服务器。
我看过对称密钥,但它们对我来说似乎不太安全。
我错过了什么,或者这很常见吗?我对整个密码学领域有些陌生。
我正在创建一个 Android 应用程序,首先需要能够将数据安全地传输到服务器。所以我想到了RSA。
我会将公钥发送给用户,让他做他必须做的事情,然后通过私人接收并解密。没关系。
但现在看来,另一方也应该有某种加密。意思是,应该有加密消息并将其发送给用户的方法,并且只允许特定用户能够阅读它。
这闻起来就像拥有 2 对密钥,并将一对中的公钥和另一对中的私钥发送给用户,并将其余的保留给服务器。
我看过对称密钥,但它们对我来说似乎不太安全。
我错过了什么,或者这很常见吗?我对整个密码学领域有些陌生。
通常的建议适用:使用 HTTPS,不要试图发明安全的消息传递协议。你很可能会失败。如果您绝对需要这样做,通常的方法是使用 RSA 密钥来加密对称会话密钥并用这些密钥加密您的数据。另请注意,您可以使用 RSA 密钥加密的数据大小受密钥大小(1024、2048 等位)的限制。对于双向通信,每一方都需要拥有对方的公钥。所以它是这样的:
在步骤 3 到 7 中颠倒 Bob 在 Bob 中的角色,以另一种方式进行通信。
但是,当然,如果您将公钥发送给某人,他们如何确定这实际上是您的密钥,而不是我的?如果您不亲自递交并出示带照片的身份证件,这绝非易事。
然后,您需要某种方法来验证来自 Bob 的(加密的)消息没有被修改(您可以将其切成两半,它仍然是有效的和可解密的;当然还有其他更复杂的攻击)。
所以只要说服你需要说服的人使用 HTTPS 或其他一些已建立的协议,不要试图重新发明轮子。
这闻起来就像拥有 2 对密钥,并将一对中的公钥和另一对中的私钥发送给用户,并将其余的保留给服务器。
这不是公钥基础设施的工作方式。你们每个人都生成自己的密钥对,并交换公钥。
客户端使用服务器的公钥加密数据到服务器并验证从服务器接收到的消息的签名。
服务器使用服务器的私钥来解密来自客户端的消息并签署发送给客户端的消息。
客户端密钥对的反向操作是相同的。