我的自定义加密握手是否安全？

Question

我为商城制作了一些广告软件，它有一堆客户端（屏幕）和一个服务器，他们从中获取内容。到目前为止，它一直在一个单独的局域网内工作，所以安全性甚至没有超出我的想法，但他们问我是否可以通过互联网使其易于管理。

我尝试了一个合理的解决方案，比如Plan A

1. 客户端发送＆＃34;我想登录消息＆＃34;
2. 服务器使用随机生成的密钥进行响应
3. 客户端发送使用所述密钥加密的密码
4. 服务器使用另一个密钥进行响应，使用第一个密钥
进行加密
5. 客户现在可以使用最后一个密钥来加密/解密任何进一步的通信

但后来我开始思考，发送另一把钥匙是什么意思？如果有人观察流量可以找出我使用的算法，那么如果他们可以根据原始的未加密密钥对它们进行解码，那么我发送的加密密钥数并不重要。

计划B

1. 客户端发送使用其密码加密的用户名

在那里停止，然后它只是一个固定的消息，将授予访问权限

计划C

1. 为客户端和服务器提供用户/密码组合（每个用户）
2. 每次客户端使用用密码加密的用户登录（用于加密此会话中的所有进一步通信）时，服务器会发送一个新密码，以便旧密码不能再次使用

很好，除了它仍然遇到计划A的问题并带来更多的问题，例如如果客户端通信在发送登录后立即切断并且没有获得新密码...

无论我采用哪种方式，如果解密算法都是可用的，那么安全性就有漏洞。

好的计划D！

1. 客户端和服务器手动获得加密密钥
2. 客户端使用密钥加密所有通信，甚至可能要求额外的密钥与第一个密钥一起使用以进一步使解密复杂化

点是，原始密钥永远不会通过网络发送。

好吧..这个似乎有效。显然任何东西都可以被花费足够的时间来攻击，但也许它足以使它不值得。问题是，这个有点笨重，客户端的每次安装都需要手动输入密钥。它很可能会变得漫长而复杂，而你平均懒惰的人可能只是通过邮件发送它......但是，目的却被打败了。

此时我不知道该怎么做。如果我可以获得与您登录工厂登录类型网站（例如此网站）相同的安全级别，那对我来说没问题。他们如何使用用户+密码处理它？<​​/ p>

Answer 1

令人钦佩的是，您已经对此深思熟虑。现在停在正确的位置，然后使用SSL / TLS。传输级安全性消除了手动保护通信通道的需要。试图推出自己的密钥交换是一个坏主意（tm），可能会导致漏洞。

Answer 2

你听说过Diffie–Hellman key exchange吗？您是否考虑使用RSA进行非对称加密？