通过不安全连接发送加密密钥的方法?

发布于 2024-10-03 19:12:24 字数 233 浏览 8 评论 0原文

我正在使用 Botan 实用程序来执行加密。当我使用 SSH 初始化与远程计算机的连接时,我可以通过安全 SSH 连接交换密钥。但是,有时我使用 inetd 建立连接,在这种情况下,inetd 连接没有安全性,但我需要使用它与远程计算机交换密钥。

我想这有一些标准,我通过不安全的通道发送公钥,远程端使用它来加密密钥,然后通过不安全的通道发送回给我,然后我可以解密以获取密钥。

Botan 支持的此类协议的示例是什么?

I am using Botan utility to perform encryption. When I initialize my connection to a remote machine using SSH, I am able to trade keys over the secure SSH connection. However, sometimes I use inetd to establish the connection, and in this case, there is no security on the inetd connection, but I need to use it to trade keys with the remote machine.

I imagine there is some standard for this whereby I send a public key over an insecure channel and the remote end uses this to encrypt a key to send back to me over the insecure channel, which I can then decrypt to get the key.

What would be an example of this kind of protocol that Botan supports?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

记忆之渊 2024-10-10 19:12:24

如果没有先前的信任或通过旁路进行的沟通,就没有办法做到这一点。 Diffie-Hellman kex 允许您建立一个针对未参与连接的其他人的安全通道,但您无法验证您是否正在与预期接收者进行通信。

经典 MITM 示例:您连接到某个远程端点,它接收您的公共信息密钥并向您发送用该密钥签名的内容。但是,您无法验证您是否已将密钥发送到真正的目的地,或者响应是否来自攻击者 - 因此,您有一个安全隧道,但您没有与谁安全通信的信息(攻击者甚至可能连接到您的预期目的地并代理流量,该流量未经加密地通过他)。

为了确保您确实正在与预期端点进行通信,您需要事先或通过安全通道交换某种主机标识。 SSH 使用“指纹”来完成此操作 - 它会在第一次连接时询问您是否信任该主机,并且您应该通过独立通道验证指纹。

Without previous trust, or communication through a side channel, there's no way to do that. Diffie-Hellman kex allows you to establish a channel secure against others who don't participate in the connection, but you cannot verify that you're communicating with the intended recipient.

Classic MITM example: you connect to some remote endpoint, it receives your public key and sends you something signed with that key. However, you have no way to verify whether you've sent your key to the real destination, or whether the response comes from an attacker - therefore, you have a secure tunnel, but you have no information with whom you're securely communicating (the attacker may even connect to your intended destination and proxy the traffic, which passes over him unencrypted).

To be sure that you are indeed communicating with the intended endpoint, you need to exchange some sort of identification of the host beforehand or through a secure channel. SSH does this using the "fingerprints" - it asks you on first connection if you trust that host, and you're supposed to verify the fingerprint through an independent channel.

末蓝 2024-10-10 19:12:24

我在类似情况下所做的就是首先安排交换私钥/公钥对,因此,我拥有每个客户端的公钥,因此当他们连接到我时,会传递一条消息,上面有时间戳,然后我就可以解密了。

如果通过了,并且时间戳有效(我使用 5 秒作为时间戳的生命周期),那么我将交换密钥,因为我们有一种安全通信的方法。

但是,这需要预先做一些事情。

如果您期望匿名用户进行连接并具有一定的安全性,那是不可能的。

我发现一篇关于此类问题非常有帮助的文章是“编程撒旦的计算机”,http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf,您试图与不可信的系统管理员进行安全通信。

What I did in a similar situation was to first arrange to get a private/public key pair exchanged, so, I had the public key of each client, so when they connected to me, a message was passed, that had a timestamp on it, that I could then decrypt.

If that passed, and the timestamp was valid (I used 5 seconds as the life of the timestamp) then I would exchange the key, since we had a way to securely communicate.

But, this required doing something upfront.

If you expect an anonymous user to connect and have some security that is impossible.

One article I found very helpful on issues like this was *Programming Satan's Computer", http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf, where you are trying to have a secure communication with an untrustworthy sysadmin.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文