服务器也不客户端可以信任（都在用户的PC上运行）。受信任的用户在其计算机上以及客户端上都有一个密钥。该算法的目标是在服务器上将受信任的用户认证为受信任的用户，而不会将密钥暴露给服务器。
我们使用的语言（游戏制作者）不是那么快也不精确。我们已经准备好了MD5哈希的实现，但我和团队都没有能力/有时间实现难以置信的硬加密算法。
答案 0 :(得分：3)
您可能只能使用MD5为每台服务器生成一个密钥。我不确定这是否正确，所以不要相信我的话。
每个服务器都有一个唯一的ID，可以是公共的，也可以是等于MD5(trusted secret + unique ID)或类似的本地机密。您必须通过某些外部安全通道将本地机密信息发送到服务器上，例如，如果它是通过HTTPS与服务器代码从单个公司站点下载的，并且如果您确保永远不会发送本地机密一个给定的唯一ID不止一次，那么我认为没关系。
然后，服务器可以将其ID与服务器ID一起发送到客户端。受信任的客户端可以为自己生成MD5(trusted secret + unique ID)，但不受信任的客户端无法生成它。这为服务器和可信客户端提供了共享密钥，可用于使用（例如）HMAC-MD5进行身份验证。
如果本地机密泄露，那么它只会让不受信任的客户端欺骗泄漏的服务器，而不是其他服务器。
显然这有弱点 - 例如服务器和可信客户端之间的MITM可以对服务器所做的任何挑战提供正确的响应，而不需要知道任何秘密。但它没有将客户端的秘密暴露给服务器，也没有将服务器的秘密暴露给客户端，所以它比没有任何东西好。
它也有加密的弱点 - MD5有点破碎。如果我是服务器而且我可以找到x MD5(x + my_id) == my_secret，那么x的机会就是密钥。我不知道在给定一个或多个本地机密的情况下查找x的计算可行性如何：这取决于MD5当前的破坏程度。
我认为考虑到你的限制，MITM绝对是不可避免的，尽管我可能错了。受信任的客户端无法将一个服务器告诉另一个服务器，特别是服务器是否使用其正确的唯一ID，因此将始终对MITM传递的任何挑战给出正确的响应。但是，如果消息包含攻击者无法控制的某些值，例如服务器生成的nonce或日期，则简单的窃听不会导致重放攻击。我不知道如何在不使用非对称加密和PKI的情况下阻止MITM，也就是说您没有时间/能力以您的语言实现的不同基本加密构建块。
可以使系统提供排序的密钥撤销。如果您设置公司权限以按需分发(random server ID, local secret)对，则服务器可以不时更新其本地密钥（并同时更改其ID）。然后，您可以更改受信任的密钥，服务器将停止对使用旧密码的客户端进行身份验证，并在下次获取ID时立即开始验证使用新客户端的客户端。如上所述，这是一个相当痛苦的移交，如果您正在构建这样的方案，您可能想要稍微软化一下。
答案 1 :(得分：1)
扩展哈罗德的评论，适用于此问题的零知识证明方案是Feige-Fiat-Shamir。 Peggy向Victor证明她知道大模数的因子分解而没有向Victor透露它。
此方案不支持撤销，如果您不相信您的“受信任”用户不泄露秘密，这是一个严重的问题。
答案 2 :(得分：0)
您不应该设计自己的加密系统。查找现有加密系统并移植它。 （即便如此，也会让你受到时间攻击......）
请允许我证明犯错是多么容易。这是一个基本的身份验证方案：
似乎安全，对吗？不。
答案 3 :(得分：0)
好吧，如果您不需要超级安全系统，那么服务器或用户应该“询问”：Am I trusted?还有一些您需要信任用户的方式。简单的方法是，当用户添加他的密钥或生成它时，它会向服务器发送一些信号：OK, I have validated, please remember that im trusted and here you go, the special passprase to check that: *Apple*. I should answer *Pear*.然后当用户连接到服务器时，服务器询问：Apple?，并且客户端回答： Pear!。服务器授权客户端。两种方式都有效。尽管如此，如果你想要一些更好的解决方案，你需要一些中央服务器，女巫会给：