对称密钥到非对称密钥切换答案

【问题标题】：Symmetric Key to Asymmetric key handoff对称密钥到非对称密钥切换
【发布时间】：2011-01-14 10:14:00
【问题描述】：

我不是密码学专家，我实际上只有一点点使用它的经验。无论如何，现在是我的一个应用程序要求我设置一些加密的时候了。请注意，该程序不会管理任何可能造成大量损害的超级关键。

无论如何，我只是想看看我使用的这个方案是否常见以及是否存在缺陷（其中可能存在完全愚蠢和严重缺陷的设计，这就是我问的原因）。

好的，我有一个客户端 -> 服务器通信。我可以在 2048 位 RSA 密钥的公共部分硬编码客户端。当客户端想要启动安全连接时，他会发送他的用户名、密码的 md5 哈希值和随机 UUID 的哈希值，所有这些都已根据服务器的公钥加密。服务器接收信息并使用其私钥解密。检查数据库以查看他的登录+通过是否有效，如果有效，则在数据库的“会话”表中创建一个新条目。这包括 SessionID、UID（用户 ID）和 UUID 哈希。使用相应会话 ID 的 UUID 作为关键字，服务器将发回一条消息，其中包含 Blowfish 加密词“成功！” + 一个随机 UUID（此消息经过数字签名，因此我们可以确定它是否来自服务器）。从那时起，当客户端向服务器发送信息时，它将带有明文 sess_id 并包含 Blowfish 加密消息，使用相应会话 ID 的河豚机密（加密存储在数据库中）作为加密/解密的密钥。

具体来说，我很好奇这个系统是否“应该工作”，或者是否有人注意到存在明显的漏洞，例如 MITM。

【问题讨论】：

您不只是想重新发明 SSL 吗？

标签： security encryption cryptography pki blowfish

【解决方案1】：

从那时起，当客户端向服务器发送信息时，它将带有明文 sess_id 并包含 Blowfish 加密消息，使用相应的 Session ID 作为密钥进行加密/解密。

如果您以明文形式发送会话 id，并将其用作加密密钥，那么安全性如何？

我认为您没有理由不能使用标准 SSL 身份验证，而让库实现者担心握手。

【讨论】：

我没有使用会话 ID 作为密钥。我将其作为对安全 MySQL 服务器上表的索引的引用发送，该表存储河豚机密，在第一次使用来自硬编码和非共享密钥的河豚加密之后（客户端的会话河豚密钥以加密方式存储在数据库中） .所以......它的设计并不是那么糟糕。 -- 我原来的帖子没有说清楚，抱歉。
你说得对，SSL 会更简单、更安全。经过进一步调查（我不知道这正是 SSL 所做的（或多或少）），我决定继续为项目使用 SSL。谢谢你的建议。

【解决方案2】：

只需使用 SSL 或 DTLS、IKEv2、HIP、EAP 或一些合适的标准协议。不要试图发明你自己的加密协议，没有人有足够的专业知识自己做这件事。据我所知，您的协议中没有足够的熵，因此您生成的密钥将非常弱。

【讨论】：

感谢您的回复。我将在这个项目中使用完整的 SSL，而不是我自己的滚动解决方案。我根本不知道这就是 SSL 是什么/实现（企业架构方面）的细节足以从一开始就使用它。既然我知道我打算这样做的方式不太安全，我会坚持使用良好的 SSL。

【解决方案3】：

我能想到的问题（尽管你忽略了大部分细节，这就是著名的魔鬼所在）：

如果您使用的是 UUID 生成器而不是真正的加密 RNG，则它的熵可能不足。不要小看这一点——在现实世界中，暗中削弱加密系统最喜欢的方法是削弱 RNG；
您的初始 RSA 加密听起来容易受到小指数攻击，并可能受到其他创造性攻击。那里的结构太多，让人不舒服；
听起来重放攻击的机会很多；
您在 Blowfish 中使用什么分组密码模式？

我建议使用 TLS/SSL - 与您自己构建的任何东西相比，它的观察时间要长得多。

【讨论】：

感谢您对此提出的非常好的想法，尤其是关于 PRNG 熵的部分。这是我特别关注的一部分，但在你说之前不知道技术上是如何提及的。从来不知道 SSL 到底是什么，我确实开始创建一个非常相似的系统，但我自己却滚动了，就像你说的那样，它几乎总是不太安全。展望未来，我将实施 SSL 加密，而不是我自己的滚动解决方案。感谢您的建议。