非对称密钥切换的对称密钥

Question

我不是加密专家，实际上我只有一点点使用它的经验。无论如何，时间到了，我的一个应用程序要求我设置一些加密。请注意，该程序不会管理任何超级严重的能够造成大量伤害的程序。

无论如何，我只是试图看看我使用的这个方案是否很常见，如果存在缺陷（其中可能存在完全愚蠢和可怕的缺陷设计，那就是我要问的原因）。

好的，我有一个客户 - ＆gt;服务器通信。客户端我可以在2048位RSA密钥的公共部分中进行硬编码。当客户端想要发起安全连接时，他会发送他的用户名，密码的md5哈希值以及随机UUID的哈希值，所有这些都是针对服务器的公钥加密的。服务器使用其私钥接收信息并解密。检查数据库以查看他的登录+传递是否正常工作＆amp;如果是，请在数据库的“会话”表中创建一个新条目。这包括SessionID，UID（用户ID）和UUID哈希。使用相应的会话ID的UUID作为关键短语，服务器将发回一条消息，其中包含Blowfish加密的单词“Success！” +随机UUID（此消息是数字签名，因此我们可以确定它是否来自服务器）。从那时起，当客户端向服务器发送信息时，它将使用明文sess_id＆amp;包括Blowfish加密消息，使用相应的会话ID的blowfish秘密（在DB中加密存储）作为加密/解密的密钥。

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

Answer 1

只需使用SSL或DTLS，IKEv2，HIP，EAP或某些合适的标准协议。不要试图发明自己的加密协议，没有人有足够的专业知识来自己做。据我所知，你的协议中没有足够的熵，所以你得到的密钥会非常弱。

Answer 2

我可以看到的问题（虽然你已经遗漏了大部分细节，这是魔鬼所熟知的地方）：

• 如果您使用的是UUID生成器而不是真正的加密RNG，则其熵可能不足。不要忽视这一点 - 在现实世界中，暗中削弱加密系统的最佳方式是削弱RNG;

• 您的初始RSA加密听起来很容易受到小指数攻击，并可能受到其他创造性攻击。那里有太多的结构让人感到舒服;

• 听起来有很多重播攻击的机会;

• 您在Blowfish中使用什么分组密码模式？

我建议使用TLS / SSL - 它有更友好的眼睛看着它比你自己构建的任何东西都要长很多。

Answer 3

  

从那时起，当客户端向服务器发送信息时，它将使用明文sess_id＆amp;包括Blowfish加密消息，使用相应的会话ID作为加密/解密的密钥。

如果您以纯文本格式发送会话ID，并将其用作加密密钥，那么这是如何安全的？

我认为没有理由不使用标准SSL身份验证，让图书馆实施者担心握手。