codesign 是代码签名啊，exe 右键属性里的那个

很多是哪些？知名的 SHA-1 根证书已经过期了。

已知 sha1 构造特定格式且有意义的内容还是很难的吧

有。pass

现在都改 SHA-256 了吧...

风险并不因为“发现它不安全”而增加
风险一直都是那么多

问有没有？那肯定有
无限的输入产生有限的输出，那碰撞的概率是必然大于零的

支付宝微信接口还支持 md5 呢

风险肯定有，但要制造一个能够实现入侵的碰撞，非常非常难，可以说几乎不可能。非对称加密还能暴破呢，只要暴破成功的时间还是以万年为单位，会有人觉得这个加密算法有风险不能用吗？

但是 sha1 快啊，虽然不安全可是碰撞成本还是很高的啊。
合理设置时间戳也可以减少安全风险，一般 api 加固够用了

哦，我还在想是在说文件 hash 校验，刚反应过来楼主说的是 API 请求签名...

事实上在有限上下文长度时，md5/sha1 也是安全的，因为单一请求时，文本长度通常不会很长....而有限文本下的安全性可以简单通过枚举法进行验证

git 用的就是 sha1

openssh 写了放弃 sha1 的原因，大公司花美金买算力破解 sha1 才是不安全的。屌丝又不花钱，sha1 就是安全的。

aws s3 v2 用的 sha1 ，v4 默认用的 sha256

我说的是代码签名，很多软件还在用 SHA-1 的签名分发

codesign 是代码签名啊，exe 右键属性里的那个

确实从一个角度上来看是可以这样理解。但从另一角度看，如果没有人做实验或者做了实验不通报粗略结果，那么我们就无从知道一个算法的安全程度究竟如何。

哪怕是用 md5 对于代码签名来说，想伪造一个既能正常运行，还能达到你目的，同时 hash 结果不变的代码，目前也没有成熟的攻击方法吧

＃11
Git 和签名有完全不同的场景，因为 Git commit 通常是 non-adversarially constructed （非别有用心构造的），所以用一个过时的散列函数危害没有那么大。如果用户对自己的 Git 仓库构造 SHA-1 碰撞，受害者是用户自己，而不是别人。请注意 Git commit 签名和 commit hash 是两码事儿，它的 commit 签名的作用对象是 commit object 被 sign 之前的内容，而不是 commit hash ，而 commit object 本身的信息是当前内容快照加上一些 commit 信息（比如消息、时间、committer ），因此可攻击的面仅限于内容快照。

当然，我的观点是 Git commit 签名意义不大，考虑用户 A 签名 commits 后又继续被别人开发，然后用户 A 的私钥泄露，那么对于新来的人，没有办法确认过去被 A 签名的 commits 到底是泄露之前签名的，还是泄露之后伪造的——除非重新签名并改写过去所有的 Git 历史。其意义不大的根本原因在于我期待软件开发历史隽永，但是签名的安全性并不隽永。

＃14

考虑我定义的签名算法 Sign(sk, msg) = 123 并且给所有程序都加入这个签名。显然该算法不安全，请问它是否有伪造的风险？

答：有“被伪造的风险”，但是此问题无意义，因为没有任何人会认为被这个不安全算法签名的程序是“有背书的”，即没有“错误认为有安全签名的风险”。

习题：过期的证书不被信任，一个证书的证书链只能追踪到过期的根证书，那么被这个证书签名的程序，是否有伪造签名的风险？

没有验证程序支持的签名，不过是一堆无甚意义的数字。

所有 CA 已经不签发新的 SHA-1 代码签名证书了（包括买了兼容性的），现在也没有 SHA-1 代码签名证书还没过期

但是，Windows 的代码签名允许一个有有效时间戳且签署时间在证书过期前的继续被视为有效签名，这也很容易理解，不然软件每三年全得换一次这谁受得了

MD5 早就可以随便碰撞了，现在可以做到一个 MD5 文件有几十个不同内容且有意义的文件

是的，有的还是 SHA-384 呢