Shell's Home

gpg pubkey ID碰撞

Jul 20, 2016 - 1 minute read - Comments

昨天和朋友碰了个头,然后做了交叉签署。

朋友签署完了,还没上传签署的时候。我手贱(幸好手贱)去server上update了一下我的key。结果发现多出一支key回来。

纳尼?

上pgp.mit.edu去搜我的邮箱,一堆key。我废弃过不少key,这就算了。有一支2014年签署的key引起了我的注意,因为ID和我的KeyID完全一致,UserID也一样。显然这是撞出来的,不过我不记得自己有做过这样的事情。

下面是我的真实key的fp:

2276 57F3 6E16 9B90 4186 2EBF 29A9 7386 0914 A01A

这是有问题的那支key的fp:

875D 447A E720 9037 84A0 7888 909F 2614 0914 A01A

可以看到,两者最后部分完全一致,这导致两者有同样的KeyID。

我点进去看了一下,后面一支key完全不是我的,签的情况也乱七八糟。但是UserID显然一致。然后汗毛一竖赶紧通知朋友。朋友看了一眼,果然签错成那支假的了。

我擦,我给你写我的fp是签名留念用的吗?

一般来说,签名很难吊销。他要是签错了,那就麻烦大了。幸好他没上传。整个删除后重新签署,这个问题总算是顺利解决。

我继续追踪,发现有趣的事来了。

这个key被很多人签署,其中有个人和我的签署人KeyID和UserID又和我互相签署的某人一致。这相当于攻击者不但碰撞伪造了我和他的外观一样的Key,而且连我们的互相签署关系都伪造出来了。。。

我OO了个XX的,这是想干嘛?

然后,某位朋友给了我这个站点:Stop it with those short PGP key IDs!

里面提到了这种伪造碰撞的现象。

同时,里面也提到了解决方法。

首先,向你的gpg.conf里面加入keyid-format 0xlong,这样可以使你的ID变为64位的长ID。碰撞难度更高,当然,也更难一眼看明白谁是谁。

其次,在写程序的时候,不要使用ShortID来指明身份了,因为这种方法显然受到了攻击。继续使用ShortID可能为你程序未来的安全性埋下隐患。

最后,验证fp的时候一定要用纸质传递,签署的时候一定要验证完整fp。

验证fp的时候一定要用纸质传递,签署的时候一定要验证完整fp。

验证fp的时候一定要用纸质传递,签署的时候一定要验证完整fp。

因为很重要所以说三遍。

Tags:

更换blog声明 CentOS 6下安装Python2.7

comments powered by Disqus