Re:No, Cellebrite Cannot “Break Signal Encryption”
by h_anna_h on Wednesday December 23, 2020 @03:01PM
(#25521543)
I presume that the idea is that the compiled binary from the source and that the binary distributed by signal would be different but have the same sha1s. It does not make a lot of sense though because one could simply use another algorithm.
Re:No, Cellebrite Cannot “Break Signal Encryption”
by gruez on Wednesday December 23, 2020 @03:04PM
(#25521567)
...or just compare byte by byte, since reproducible builds provides you with an .apk to compare against, not just a hash.
Re:No, Cellebrite Cannot “Break Signal Encryption”
by mechnesium on Wednesday December 23, 2020 @03:08PM
(#25521609)
AFAIK, you cannot view applications on iOS unless your device is jailbroken. Apps are completely opaque since there is no traversable filesystem. On Android, it is a little simpler.
The vast majority of non-technical users have no knowledge about hexadecimal file comparisons or checksums. They see an app that promises privacy, and they click download.
Re:No, Cellebrite Cannot “Break Signal Encryption”
by mechnesium on Wednesday December 23, 2020 @02:56PM
(#25521474)
Thanks for pointing out collision vs. preimage. Interesting distinction.
>[5] https://shattered.io/
Collision attacks are an issue when using md5/sha1, but I don't see how it's relevant in this case. If state actors wants to replace the signal apk with a backdoored one, they'll need to pull off a preimage attack, not a collision attack. A collision attack wouldn't be useful because you still need the original publisher to sign the apk for you, which seems unlikely considering OWS isn't a CA or anything. If OWS was compromised by state actors into signing, then they can just sign the backdoored version directly, no need for a collision attack.