加密套接字的简单握手
我需要保护客户端和服务器之间的套接字连接。不幸的是，SSL/TLS 在客户端平台上不可用（所以对于那些会自动回答“不要推出自己的安全性”的人：不要:-)），我需要构建一些东西我。我想出了这个简单的方案（基于我对 SSL 的小知识，可能已经过时了）：
- 客户端连接到服务器
- 客户端生成一个用于对称加密的密钥
- 它使用服务器的公钥对其进行加密（它知道它，因为它是硬编码的）在程序中）
- 它将该密钥发送到服务器
- 服务器用其私钥对其进行解密
- 通信开始，并以消息的形式完成，每个消息都对称编码。
- 每条消息都包含一个序列号，因此即使实际内容相同，也不会有两条消息相同。 （如果这甚至没有必要，请告诉我们，因为将其省略会使事情变得更容易）
据我所知，这是安全的。 MITM 是不可能的，因为他无法解密生成的密钥。客户端软件本身是从 HTTPS 网站下载的。唯一的“缺陷”是嗅探器仍然可以看到发送的消息的数量和大小，但这不是问题。
您的专家意见是什么？
我需要研究要使用的特定加密（取决于客户端上可用的加密），但我认为 RSA 和 AES-256 是安全的选择？
I need to secure a socket connection between my client and server. Unfortunately SSL/TLS is not available on the client platform (so to those who would automatically answer "don't roll your own security": don't :-) ), and I need to build something myself. I've come up with this simple scheme (based on my small, probably outdated knowledge of SSL):
- Client connects to server
- Client generates a key for symmetric encryption
- It encrypts this with the public key of the server (which it knows since it's hardcoded in the program)
- It sends that key to the server
- The server decrypts it with its private key
- Communication begins, and is done in the form of messages, each encoded symmetrically.
- Each message includes a sequence number, so no two messages will be the same even if their actual contents are the same. (If this is not even neccessary, do tell, because leaving it out would make things easier)
As far as I can see, this is secure. MITM is impossible because he cannot decrypt the generated key. The client software itself is downloaded from an HTTPS website. The only "flaw" is that a sniffer can still see the amount and size of the messages that are sent, but that's not a problem.
What are your expert opinions?
I need to look into the specific encryptions to use (depending on what's available on the client), but I assume RSA and AES-256 are safe choices?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要您提供足够长的密钥，RSA 和 AES-256 都是安全的选择。
RSA and AES-256 are safe choices as long as you provide a long enough key.
是的，这就是 SSL 的基本（简化的）想法。至于密钥长度，AES-256 对于对称来说就可以了，此时 RSA 2048 应该就可以了。不确定系统预计能持续多久，但您可能需要考虑加密（越来越大）密钥大小一直被破坏的速度。因此，这可能是您的硬编码想法的问题，而不是将其保留为用户指定的。
我不确定您为什么要对其中的公钥进行硬编码。如果它被撤销，或者他们（无论出于何种原因）更改密钥，或者如果他们想要使用不同的证书连接到不同的站点，或者任何其他可能发生的事情，这可能会从一种便利变成一个错误快速地。
您是否考虑过非对称侧的椭圆曲线加密？不确定客户端是什么，但 ECC 越来越流行（尤其是在移动设备中），因为它使用比 RSA 小得多的密钥大小，因此在处理时需要更少的资源。
Yes, that's the basic (simplified down) idea for SSL. As for the key lengths, AES-256 is fine for the symmetric, and RSA with 2048 should be fine at this time. Not sure how long the systems are expected to last, but you might want to consider how quickly encryption (increasingly larger) key sizes are being broken all the time. So that might be an issue with your idea of hardcoding, versus leaving this as user-specified.
I'm not sure why you'd want to hardcode the public-key in there. If it ever gets revoked, or they ever (for whatever reason) change keys, or if they want to connect to a different site using a different certificate, or whatever other things might happen, this might go from being a convenience to a bug pretty fast.
Have you considered elliptic curve encryption on the asymmetric side? Not sure what the client is, but ECC is getting popular (especially in mobile) since it uses significantly smaller key sizes than RSA and therefore requires less resources in processing.