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

Question

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

无论如何，我只是想看看我使用的这个方案是否常见，以及是否有缺陷(其中可能有完全愚蠢的设计&可怕的缺陷，这就是我问的原因)。

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

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

Answer 1

我可以在脑海中看到的问题(尽管您遗漏了大部分细节，这是众所周知的魔鬼所在的地方)：

• 如果你使用的是UUID生成器而不是真正的加密RNG，它可能没有足够的熵。不要忽视这一点-在现实世界中，最受欢迎的秘密削弱加密系统的方法是削弱RNG；
• 你最初的RSA加密听起来像是容易受到小指数攻击，并可能受到其他创造性的攻击。有太多的结构comfortable;
• It听起来有很多重播攻击的机会；
• 你对Blowfish使用什么块密码模式？

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

Answer 2

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

Answer 3

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

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

我不明白为什么您不能使用标准的SSL身份验证，并让库实现人员担心握手。