【问题标题】:Private key compromised, how to distribute new public keys? Client server model via asymmetric key encryption私钥泄露,如何分发新的公钥?通过非对称密钥加密的客户端服务器模型
【发布时间】:2016-11-30 06:04:00
【问题描述】:

我正在尝试通过 libsodium 为应用程序设置客户端/服务器通信。到目前为止,我计划使用硬编码的公钥分发应用程序。服务器将保留其秘密密钥,而不会共享它。这应该让用户加密消息并将它们发送到服务器,密钥在那里解密消息。

如果服务器上的密钥被泄露(我不确定如何泄露,但以防万一)如何将新的公钥分发给所有客户端?有没有一种方法可以在不需要分发新公钥的情况下生成新的密钥?比如:

make_new_secret( secret_buffer, previous_public );

我希望有一个非常简单的解决方案,不需要复杂的算法来安全地分发新的公钥。如果必须在制作新公钥的同时制作新的私钥,可以使用哪些算法将公钥从服务器安全地分发到客户端?

其他信息(请随意跳过):

我们可以阅读here,其中 Glenn Fiedler(libyojimbo 的作者,使用 libsodium)谈到了“只需滚动一个新的私钥”的想法。

如果有办法重用旧公钥并使用 libsodium 创建新私钥,我很乐意阅读它。我已经浏览了文档,但还没有看到任何功能。所以我担心我可能不得不深入研究更复杂的算法来安全地分发新的公钥。

我已经查看了Diffie Hellman,但似乎需要双方从一个共同的“颜色”开始。所以我想我的问题是关于达成新的商定起始颜色。

【问题讨论】:

    标签: encryption encryption-asymmetric libsodium


    【解决方案1】:

    公钥/私钥总是pair(EC 有两个公钥除外,它们本质上是相同的)。所以如果你的服务器私钥被泄露或者你决定roll它,你需要客户端知道你的服务器新的公钥。

    挑战是真实的。如果您对其进行硬编码,那么您必须重新编译/重新分发应用程序给您的客户。

    我不了解您的整个用例,但如果您尝试进行授权,请查看 OAUTH2,它允许您从服务器向您的客户端发出临时(可在服务器上配置)令牌。在这种情况下,您可以撤销 OAUTH 令牌,以防服务器或客户端受到威胁并且您(您的服务器)可以完全控制它。

    【讨论】:

    • 好的,很高兴知道这是一个真正具有挑战性的话题。我的用例是通过 Steam 发布的游戏。所以在这种情况下,将新的二进制文件重新分发给用户实际上不是问题。所以这是有道理的!就我而言,我正在为 NAT-puncthrough 设置代理服务器,就像 STUN 服务器一样,但使用自定义协议。
    • 明确一点:我只是想保护类似 STUN 的服务器本身,并且一直在阅读有关加密的内容。无论如何,谢谢你的回答!
    猜你喜欢
    • 2019-11-27
    • 2019-07-09
    • 2016-02-27
    • 1970-01-01
    • 1970-01-01
    • 2018-07-19
    • 1970-01-01
    • 2010-10-30
    • 2013-04-06
    相关资源
    最近更新 更多