Google command line example for signing apk files:

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name

source: http://developer.android.com/tools/publishing/app-signing.html

As you know, both MD5 and SHA1 are considered seriously flawed (With MD5 badly broken in practice too). So is signing android apk files with SHA1 hash secure enough? If no, Google guys should know about that and I am wondering why they have provided such an example. Can I use another algorithm for signing android apks?

  • 3
    If this comment is accurate, Android 4.3 and earlier require SHA1withRSA. At the present time, Android 4.3 and earlier is still a substantial portion of the Android device ecosystem. Mar 30, 2016 at 17:20

2 Answers 2


MD5 and SHA-1 have flaws with regards to collisions (in the case of SHA-1, these flaws are "theoretical" in that no actual collision has been produced yet). Collisions are not necessarily a problem, depending on the context.

A collision is a pair of inputs m and m' that are distinct, but hash to the same value. Since signature algorithms operate on hashed messages, a signature on the first message of a collision pair would also be valid for the other message, mechanically. Collisions are distinct from second preimages in the following sense:

  • in a second preimage, the attacker is shown a message m and is challenged with finding a distinct m' that collides with m;
  • in a collision, the attacker chooses both m and m'.

Currently, there is no known second preimage attack on SHA-1 and only a very very theoretical second preimage attack on MD5 (effort of more than 2120).

App signing is about accountability. Normally you would not want to install an app that may do bad things; the signature does not guarantee that the app does not do bad things, but it gives the user retaliation power: the signer should not be able to deny having signed the app. This is important to remember: the signature does its job as long as it allows tracing back to the culprit.

An attacker might want to make two versions of his app, the two versions hashing to the same value, and thus using the same signature value. One version would be "honest", and the other would hijack your phone or enact similar naughtiness. But what it would gain to the attacker? If application m and application m' share the same signature value, then the signature "proves" that the author of the application really wrote both... which is entirely true! The security property of the signature, the accountability, is still valid in the presence of collisions.

What the attacker really wants is a second preimage: he wants to make a bad app which is signed by somebody else. For that, he needs to take an existing "honest" app, and make a new one that hashes to the same value, thereby allowing him to borrow the signature value. Right now, nobody knows how to do that with a RSA/SHA-1 signature (or, for that matter, with a RSA/MD5 signature).

Collisions can be a problem when the attacker gets to choose what will be signed by somebody else. This is what happened with a demonstration involving RSA/MD5 and certificates. This, however, does not apply to your context, when what you sign is your own app. Collisions on MD5 or SHA-1 would be relevant if we imagined a situation that would go thus:

  1. Attacker makes a pair of apps, an honest one, and a malicious one, that hash to the same value.
  2. Attacker submits the first app to someone who can sign app.
  3. The signer inspects the app code thoroughly, sees that everything looks fine in it, and signs it.
  4. The attacker then reuses the signature value on his malicious app.

Even in that case, while the signature would point at the signer, that signer would know, in case of trouble, that the malicious app is not what he signed. In fact, he would simply exhume the "honest app" from his emails, show that both the honest and malicious app are a colliding pair for the hash function, thereby demonstrating the malicious intent of the app author (you don't get collisions out of bad luck; you have to do it on purpose).

Summary: known flaws of MD5 and SHA-1 with regards to collisions do not endanger the security model of app signing. It still is a nice idea to investigate usage of more modern and robust functions such as SHA-256, but there is no urgency.

  • Noticed that Google removed command line from their manuals and after using Generate signed APK IDE tool I got in keytool -v -list -keystore app/upload_keystore.jks output Signature algorithm name: SHA1withRSA (weak) <upload> uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. It seems to be OK according to your post because Subject Public Key Algorithm: 2048-bit RSA key is up-to-date? Jan 28, 2021 at 14:34
  • Any command to update the 1024 SHA1withRSA (weak) bit weak key to 2048 bit RSA key
    – sejn
    Dec 20, 2021 at 9:31
  • Update to SHA1 collision attacks: In late 2016 there was the first successful collision attack which went pretty viral: shattered.io
    – Cyb3rKo
    Apr 28 at 21:52

Signing has no deal or dependence in what is being signed - it's a cryptographical algo's strength/weakness projected to the signed subject. Try SHA-512 or any SHA-2 member, it should be working. The example takes root in a moment long-time-ago when it was written, so it's just outdated.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .