用于签署 apk 文件的 Google 命令行示例：
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name
来源：http : //developer.android.com/tools/publishing/app-signing.html
如您所知，MD5 和 SHA1 都被认为存在严重缺陷（MD5 在实践中也被严重破坏）。那么使用 SHA1 哈希签名 android apk 文件是否足够安全？如果不是，谷歌的人应该知道这一点，我想知道他们为什么提供这样的例子。我可以使用另一种算法来签署 android apks 吗？
MD5 和 SHA-1 在碰撞方面存在缺陷（在 SHA-1 的情况下，这些缺陷是“理论上的”，因为尚未产生实际的碰撞）。碰撞不一定是问题，具体取决于上下文。
冲突是一对不同的输入m和m'，但散列到相同的值。由于签名算法对散列消息进行操作，因此碰撞对的第一条消息上的签名也将机械地对另一条消息有效。在以下意义上，碰撞与第二个原像不同：
目前，没有已知的对 SHA-1 的第二次原像攻击，只有非常非常理论上的对 MD5 的第二次原像攻击（超过 2 120的努力）。
应用签名是关于问责制。通常，您不想安装可能会做坏事的应用程序；签名并不能保证应用程序不会做坏事，但它赋予了用户报复的权力：签名者不应该能够否认已经签署了应用程序。记住这一点很重要：只要签名允许追溯到罪魁祸首，它就可以发挥作用。
攻击者可能想要制作他的应用程序的两个版本，这两个版本散列到相同的值，因此使用相同的签名值。一个版本是“诚实的”，另一个版本会劫持你的手机或做出类似的顽皮。但它会给攻击者带来什么好处呢？如果应用程序m和应用程序m'共享相同的签名值，则签名“证明”应用程序的作者确实编写了两者……这完全正确！签名的安全属性，即责任性，在存在冲突的情况下仍然有效。
攻击者真正想要的是第二个原像：他想要制作一个由其他人签名的不良应用程序。为此，他需要使用现有的“诚实”应用程序，并制作一个新的哈希值相同的应用程序，从而允许他借用签名值。现在，没有人知道如何使用 RSA/SHA-1 签名（或者，就此而言，使用 RSA/MD5 签名）来做到这一点。
当攻击者可以选择由其他人签名的内容时，冲突可能会成为问题。这就是涉及 RSA/MD5 和证书的演示所发生的情况。但是，当您签署的是您自己的应用程序时，这不适用于您的上下文。如果我们想象这样的情况，MD5 或 SHA-1 上的冲突将是相关的：
即使在这种情况下，虽然签名会指向签名者，但签名者会知道，万一遇到麻烦，恶意应用程序不是他签名的。事实上，他只是简单地从他的电子邮件中挖掘出“诚实的应用程序”，表明诚实的应用程序和恶意应用程序都是哈希函数的碰撞对，从而证明了应用程序作者的恶意意图（你不会得到冲突）运气不好；你必须故意这样做）。
总结： MD5 和 SHA-1 在冲突方面的已知缺陷不会危及应用签名的安全模型。研究更现代和更强大的功能（如 SHA-256）的使用仍然是一个好主意，但没有紧迫性。
签名与所签名的内容没有任何交易或依赖关系——它是一种加密算法的强度/弱点，投射到已签名的主题上。尝试 SHA-512 或任何 SHA-2 成员，它应该可以工作。该示例在很久以前编写时就已经扎根了，所以它已经过时了。