You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I saw this recent commit 74c85c4 and noticed that the documentation page on how to "Verify-APK-is-genuine" recommends to compare the SHA-1 hash of the APK certificate against the hash stated in the documentation.
SHA-1 is not a collision-resistant hash function. It is practically feasible to find two inputs that have the same SHA-1 hash. Collision resistance is crucial to verify that you have downloaded the genuine APK. If an attacker manages it to craft a bogus certificate that has the same hash as the honest one, you cannot tell the difference by looking at the hash.1
Therefore, it is recommended to use a cryptographic hash function that is still considered secure such as the SHA-2 and SHA-3 families of hash functions. See, e.g., Table 4.1 and Remark 4.2 on page 44 of the BSI recommendations.
A code search on GitHub shows a few places, where SHA-1 is used in this repository:
print('[WARN] Failed to parse keytool result: '+str(e));
returnNone
release_types= {
"2ScaPj41giu4vFh+Y7Q0GJTqwbA=": "GitHub",
"nyupq9aU0x6yK8RHaPra5GbTqQY=": "F-Droid",
"dQAnHXvlh80yJgrQUCo6LAg4294=": "Google Play"
PS: Is there a reason for Base64? Usually I see hashes encoded in hex. Maybe B64 is more common in the Android/Java world? Just being curious.
Footnotes
The actual task that an attacker has to perform is harder than finding a collision (i.e., finding two arbitrary files with the same hash). It needs to break second-preimage resistance (i.e., finding a file that has the same hash a given genuine file). This is however no reason to still use SHA-1. ↩
The text was updated successfully, but these errors were encountered:
Well, even if I make the changes, you should double check that I put the right hashes there and not blindly trust a random stranger from the internet.
Then I don't know where I would get the APK hashes from. Download them from the three platforms and compute them myself?
Also, since the mentioned commit, the GitHub hashes in postbuild.py and the Verify-APK-is-genuine file are inconsistent.
Hi,
I saw this recent commit 74c85c4 and noticed that the documentation page on how to "Verify-APK-is-genuine" recommends to compare the SHA-1 hash of the APK certificate against the hash stated in the documentation.
SHA-1 is not a collision-resistant hash function. It is practically feasible to find two inputs that have the same SHA-1 hash. Collision resistance is crucial to verify that you have downloaded the genuine APK. If an attacker manages it to craft a bogus certificate that has the same hash as the honest one, you cannot tell the difference by looking at the hash.1
Therefore, it is recommended to use a cryptographic hash function that is still considered secure such as the SHA-2 and SHA-3 families of hash functions. See, e.g., Table 4.1 and Remark 4.2 on page 44 of the BSI recommendations.
A code search on GitHub shows a few places, where SHA-1 is used in this repository:
syncthing-android/wiki/Switch-between-releases_Verify-APK-is-genuine.md
Lines 21 to 29 in 03454c1
syncthing-android/syncthing/build-syncthing.py
Lines 29 to 30 in 03454c1
syncthing-android/syncthing/build-syncthing.py
Lines 266 to 273 in 03454c1
syncthing-android/app/postbuild.py
Lines 64 to 76 in 03454c1
PS: Is there a reason for Base64? Usually I see hashes encoded in hex. Maybe B64 is more common in the Android/Java world? Just being curious.
Footnotes
The actual task that an attacker has to perform is harder than finding a collision (i.e., finding two arbitrary files with the same hash). It needs to break second-preimage resistance (i.e., finding a file that has the same hash a given genuine file). This is however no reason to still use SHA-1. ↩
The text was updated successfully, but these errors were encountered: