现在 SHA1 已经属于不安全的 hash 算法了，但是很多软件的 codesign 还是 SHA1 的，是否有伪造签名的风险？
drymonfidelia · 11 天前 · 4698 次点击
第 1 条附言 · 11 天前
codesign 是代码签名啊，exe 右键属性里的那个
 |
1
geelaw 11 天前  1
很多是哪些？知名的 SHA-1 根证书已经过期了。
|
 |
2
Xbluer 11 天前 via iPad
已知 sha1 构造特定格式且有意义的内容还是很难的吧
|
 |
3
hefish 11 天前
有。pass
|
 |
4
crackidz 11 天前
现在都改 SHA-256 了吧...
|
 |
5
julyclyde 11 天前
风险并不因为“发现它不安全”而增加
风险一直都是那么多 |
|
6
julyclyde 11 天前
问有没有？那肯定有
无限的输入产生有限的输出，那碰撞的概率是必然大于零的 |
 |
7
dzdh 11 天前
支付宝微信接口还支持 md5 呢
|
 |
8
xuanbg 11 天前
风险肯定有，但要制造一个能够实现入侵的碰撞，非常非常难，可以说几乎不可能。非对称加密还能暴破呢，只要暴破成功的时间还是以万年为单位，会有人觉得这个加密算法有风险不能用吗？
|
 |
9
k9982874 11 天前 via Android
但是 sha1 快啊，虽然不安全可是碰撞成本还是很高的啊。
合理设置时间戳也可以减少安全风险，一般 api 加固够用了 |
|
10
crackidz 11 天前
哦，我还在想是在说文件 hash 校验，刚反应过来楼主说的是 API 请求签名...
事实上在有限上下文长度时，md5/sha1 也是安全的，因为单一请求时，文本长度通常不会很长....而有限文本下的安全性可以简单通过枚举法进行验证 |
 |
11
hamsterbase 11 天前
@geelaw git 用的就是 sha1
|
 |
12
tool2dx 11 天前 via Android
openssh 写了放弃 sha1 的原因，大公司花美金买算力破解 sha1 才是不安全的。屌丝又不花钱，sha1 就是安全的。
|
 |
13
trzzzz 11 天前
aws s3 v2 用的 sha1 ，v4 默认用的 sha256
|
 |
14
drymonfidelia OP @geelaw 我说的是代码签名，很多软件还在用 SHA-1 的签名分发
|
|
15
drymonfidelia OP @crackidz codesign 是代码签名啊，exe 右键属性里的那个
|
 |
17
wwqgtxx 11 天前
哪怕是用 md5 对于代码签名来说，想伪造一个既能正常运行，还能达到你目的，同时 hash 结果不变的代码，目前也没有成熟的攻击方法吧
|
|
18
geelaw 11 天前 2
@hamsterbase #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 历史。其意义不大的根本原因在于我期待软件开发历史隽永，但是签名的安全性并不隽永。 @drymonfidelia #14 考虑我定义的签名算法 Sign(sk, msg) = 123 并且给所有程序都加入这个签名。显然该算法不安全，请问它是否有伪造的风险？ 答：有“被伪造的风险”，但是此问题无意义，因为没有任何人会认为被这个不安全算法签名的程序是“有背书的”，即没有“错误认为有安全签名的风险”。 习题：过期的证书不被信任，一个证书的证书链只能追踪到过期的根证书，那么被这个证书签名的程序，是否有伪造签名的风险？ 没有验证程序支持的签名，不过是一堆无甚意义的数字。 |
 |
19
ZeroClover 11 天前
所有 CA 已经不签发新的 SHA-1 代码签名证书了（包括买了兼容性的），现在也没有 SHA-1 代码签名证书还没过期
但是，Windows 的代码签名允许一个有有效时间戳且签署时间在证书过期前的继续被视为有效签名，这也很容易理解，不然软件每三年全得换一次这谁受得了 @wwqgtxx MD5 早就可以随便碰撞了，现在可以做到一个 MD5 文件有几十个不同内容且有意义的文件 |
 |
21
tdxdxoz 11 天前 via Android
sha1 不安全，指的是（花费比较大的算力）可以构造碰撞，也就是不同消息有相同的哈希值。
如果是要对任意给定的哈希值找原像/第二原像，也就是构造一个消息哈希值正好等于这个，即使 md5 目前也是做不到的。 |
 |
22
linglingling 11 天前 via Android
安全是相对的，没有绝对的安全。当你的服务（产品）价值一美元时，破解成本大于一美元，就是安全的。当然，现实中可能很难衡量价值，但大概的还是可以衡量的，如民用的没必要追求金融级别安全，金融没必要追求军事级别安全。
|
 |
23
proxytoworld 11 天前
除非能够把木马/病毒的 sha1 和已有的已签名的 exe 的 sha1 弄成一样，否则没有意义
|
 |
24
edwardzcn98 10 天前
@geelaw #18 对于 git 的 commit hash 我看完后的理解：那用 sha-1 或者 md5 都可以吧？虽然不抗碰撞但是这种场景下不会有人去费劲构造，所以至今不需要更新散列函数。而对于 Git commit 的签名（之前没有仔细想过是对快照+元信息而非 commit hash 签名，~~GitHub 上这个 verified 标志挂在 commit hash 上给了我一种错觉~~），我倾向于理解为 git 加入这种签名更像是一种代码提交者的“宣告”（这是我用这只笔写的），并没有意图用数字签名来溯源验证提交者，如果私钥泄露就相当于自愿放弃之前提交的宣告，但对于代码提交本身是无影响的。
|
 |
25
shenyuzhi 9 天前
散列算法不全是用在安全场合，有时候是为了性能，有时候（比如 Git ）只是为了要一个标识符
|
 |
26
frayesshi1 9 天前
@shenyuzhi #25 sha1 或者 sha265 很多场景是加盐用的，比如客户端和服务端通信，有一个字段就是盐，用来验证是否是正确的客户端
|
Select Language