在公钥基础设施又一次失败之后,我在想整个事情到底有多糟糕。不可否认地将身份与公钥相关联的业务,以及我们为实现它所做的所有工作,开始感觉就像在山上溜冰一样。原谅我,我只是在这里大声思考。
我开始思考ToR 隐藏服务协议及其解决此问题的方法。“隐藏的服务名称”(像任何其他 URL 一样在地址栏中输入)实际上是从公钥派生的 - 所以你最终会访问类似的网站kpvz7ki2v5agwt35.onion
- 但你不需要证书或 PKI、公钥和仅域就足以证明它们属于一起(直到您能够产生冲突,但这是另一回事)。现在很明显这有一个问题——DNS 的全部意义在于提供人类可读的 IP 地址映射。
这引出了我最后的、可能有缺陷的建议;为什么我们不使用从公钥生成的 IP 地址?(相反的方法起初听起来更方便,但由于明显的加密原因不能工作)。
我们有一个巨大的 IPv6 地址空间。一个 1024 位的 RSA 密钥对被认为最多有大约 80 位的熵。那么为什么不拆分一个 80 位段,并将公共 RSA 密钥映射到该段中的 IP 地址呢?
我的头顶上有一些缺点;
- 因此,攻击者可以生成一个密钥对,并立即知道该密钥对将在哪个服务器上使用,如果这样的服务器存在的话。也许 80 位空间可以扩展为使用 4096 位 RSA 密钥,据信最大熵约为 256 位,使得这样的搜索不可行(不幸的是,我们需要 IPv7+ 和 512 位左右的地址才能适应)。这种攻击也没有听起来那么糟糕,因为它没有目标。这种攻击可以通过在 key->IP 过程中加入盐来缓解,服务器在连接时将其发送给客户端。这种盐使每个服务器的 key->IP 进程都是唯一的。
- 攻击者可能会使用已知的盐对密钥空间进行暴力破解,直到它们与选定的 IP 匹配。这是有针对性的攻击,所以有点吓人。但是,使用慢速(1-3 秒)算法进行从公钥到 IP 的映射可以缓解这种情况。使用盐还意味着这种蛮力只适用于单个 IP,并且必须针对每个目标 IP 重复。
为了试图阻止mods关闭它,我会尽力把它变成一个问题;这个想法在某些方面完全有缺陷吗?过去有没有尝试过?我只是在闲逛吗?