从安全方面来说，用户是系统中最薄弱的环节。不过「聪明的」用户总是会找出各种理由把责任推卸给「技术」。甚至研究者有时也会落入这种陷阱。
不久前在知乎上有一个关于 MD5 的讨论。不得不说 MD5 是一种非常弱的 hash 算法。考虑到使用 SHA-1 等更强算法的额外负担完全可以忽略，我建议无条件的避免使用 MD5。但是从另一个方面来说，到底多少安全问题真正的责任在于 hash 算法的脆弱性？我在知乎上的总结是这样的（下面有些描述是符号化的，但在知乎上用的是非符号化语言。如果二者造成理解上的差异我为知乎上的不准确抱歉）：
给定一个 hash 算法 f(x)，对 f(x) 的「破解」有下面几种方法（注意「破解」不能等同于攻击。破解是非蛮力攻击。所以以下方式均有「比穷举算法效率更高」这个限制）：
- 使用比穷举算法效率更高的方法得到 x1 和 x2，满足 f(x1) = f(x2)；（可称为随机盲目碰撞）
- 给定 x1，使用比穷举算法效率更高的方法得到 x2，满足 f(x1) = f(x2)；
- 给定 x1，使用比穷举算法效率更高的方法得到满足约束 A 的 x2，满足 f(x1) = f(x2)。约束 A 越严格，达成实质攻击的可能越大。比如，若 A 是描述自然的英语或者汉语，则任意的签名欺诈可行矣。
目前在理论界只有破解方式 1 得到了一些针对 MD5 级别的弱 hash 算法的突破。方式 2 和 3 在理论上的可能性也还未证实，甚至于对最弱的 hash 算法即使用蛮力也无法得到方式 3 中真正可以施行欺诈的 x2。我认为方式 1 很难达成实质的攻击。但是有研究者不同意这个观点（本地存档）。这个链接给出了一个方法，通过方式 1 的随机盲目碰撞也能达成实质的数字签名欺诈。果真如此吗？
错！
（以下描述需要理解刚才给出的链接内容）
Caesar 的错误不在于使用了弱 hash 算法，而是他轻易相信了 Alice 给他的 PostScript 格式的文件。他没有审查这个文件的实质代码（尽管 PostScript 文件的源代码实际上是可读的），而是轻信了一个 PostScript viewer 一时 render 出来的外观就匆匆地数字签名了。如果把 PostScript 文件变成可执行文件，把 PostScript viewer 变成操作系统，Caesar 变成某家水果公司。那么以上关于 Caesar 和 Alice 的情景无异于：一个开发者给水果公司一个 app，水果公司运行了一下发现没问题，然后水果公司就用公司证书给这个 app 签名并将签名后的 app 发回给开发者了。那么水果公司因此背上任何黑锅都是咎由自取。事实是：
- 水果公司不会用自己的证书，而是用自己的证书认证开发者证书，然后要求开发者用自己的开发者证书签名；
- 水果公司要保留追溯开发者的机制，在后期发现 app 违规时可以追加惩罚。
所以，数字签名技术提供的信任是有约束的。对简单的可审查文件（如纯文本）才能任意签署。对复杂的不可审查文件（如可执行文件，复杂结构化文档，特别是带有动态内容的文档 —— 其实质等同于可执行文件，有些甚至达到了 Tuning-complete 级别）必须坚持「谁产生谁签署」的原则，而且必须有后续的法律追溯机制。更近一步说，对复杂的不可审查文件的轻信是任何技术都无法挽救的安全溃败。
其实上文提到的这个研究者在最后一页中提到了采用其它文件格式作为解决方法。但是他明显认为和采用更强的 hash 算法相比这是一个次要因素，而且他提出的居然是 Word 文档，一种内在格式和外观差异与 PostScript 不相上下的格式，而非「所见即所存」的简单文本格式。我曾经参与过几次安全培训，那些很有经验的讲师一般也会在几天的培训里不经意举出一两个他们认为的技术上的安全漏洞，而实为用户「盲目轻信」导致的问题。从信噪比的角度看，这些疏忽对那些安全专家的知识价值可说瑕不掩瑜，但也说明在人类心理和行为模式方面的安全才是最脆弱的。
技术奇异点 