4 ms·

> it's possible enough to tear through our binaries No, it's not "possible enough" and I strongly suspect you fully realize that. A backdoor doesn't need to b

> it's possible enough to tear through our binaries No, it's not "possible enough" and I strongly suspect you fully realize that. A backdoor doesn't need to be in a form of an IF statement or something comparably obvious and silly. It can be a weakly seeded PRNG that would allow a "determined party" to brute-force the key exchange in a reasonable time. That would take man-years to fish out from a binary, and that's without considering that you may (be forced to) distribute an altered binary on demand and to specific targets only. So in the end all we have - realistically - is in fact just your word. There's no way for you to prove that you are trustworthy by pointing at some random binary. The only option is to distribute reproducible builds from an audited open source.

buzzert 7y ago
I disagree that it would take man-years to fish that out from a binary. Black hat and white hat hackers do this all the time.
- londons_explore 7y ago
  I agree. The crypto used is industry standard, and the actual process all the way from random number generation to deriving a key is relatively easy to follow. Active ways to attack the client to make it leak the key are far more worrying - but even an open source project wouldn't protect against that.
  - huhtenberg 7y ago
    Again, it may very well be a vanilla TLS, but then you have a bit of code in some obscure corner that repoints random() to an alternative weaker implementation when some conditions are met, including, for example, not being run under a debugger and not having certain popular functions trampolined. Good luck finding even this without a fine comb. And that's us just getting started with code flow obfuscation. No source = no trust. It's as simple as that.
wbl 7y ago
Juniper reveled the Screen OS backdoor with a quiet patch over Christmas. Within a month the backdoor was fully understood.
- huhtenberg 7y ago
  They had a diff, they knew where it was. This helps a lot.
martinbooth 7y ago
Distributing an altered binary to specific targets should be impossible as WhatsApp don't control the distribution, Apple and Google do. They would also have to be complicit too for a targeted attack to be feasible. By having to distribute the same binary to everyone it is much harder to conceal a backdoor
- anoncake 7y ago
  That doesn't help against attacks by US authorities. If they can make Facebook create a backdoor, they can make Apple and Google distribute it. Signal has the same issue.
- vbezhenar 7y ago
  Are you sure that there's no way for whatsapp to download and execute some code which will lead to upload of protected information? Simple example: I'm sure that whatsapp main window is webview. Imagine that application inserts some kind of resource (e.g. CSS) from whatsapp server. So now whatsapp server can serve slightly altered CSS which will leak secret data via custom fonts, etc and you won't be able to find that, unless you're intercepting all traffic and can decrypt it (and apps nowadays love to pin certificates). This is imaginary attack, I have no idea whether whatsapp does that. But HTML is a powerful and dangerous beast, yet it's used a lot in applications for rich media.

buzzert 7y ago

I disagree that it would take man-years to fish that out from a binary. Black hat and white hat hackers do this all the time.

londons_explore 7y ago
I agree. The crypto used is industry standard, and the actual process all the way from random number generation to deriving a key is relatively easy to follow. Active ways to attack the client to make it leak the key are far more worrying - but even an open source project wouldn't protect against that.
- huhtenberg 7y ago
  Again, it may very well be a vanilla TLS, but then you have a bit of code in some obscure corner that repoints random() to an alternative weaker implementation when some conditions are met, including, for example, not being run under a debugger and not having certain popular functions trampolined. Good luck finding even this without a fine comb. And that's us just getting started with code flow obfuscation. No source = no trust. It's as simple as that.

wbl 7y ago

Juniper reveled the Screen OS backdoor with a quiet patch over Christmas. Within a month the backdoor was fully understood.

huhtenberg 7y ago
They had a diff, they knew where it was. This helps a lot.

martinbooth 7y ago

Distributing an altered binary to specific targets should be impossible as WhatsApp don't control the distribution, Apple and Google do. They would also have to be complicit too for a targeted attack to be feasible. By having to distribute the same binary to everyone it is much harder to conceal a backdoor

anoncake 7y ago
That doesn't help against attacks by US authorities. If they can make Facebook create a backdoor, they can make Apple and Google distribute it. Signal has the same issue.
vbezhenar 7y ago
Are you sure that there's no way for whatsapp to download and execute some code which will lead to upload of protected information? Simple example: I'm sure that whatsapp main window is webview. Imagine that application inserts some kind of resource (e.g. CSS) from whatsapp server. So now whatsapp server can serve slightly altered CSS which will leak secret data via custom fonts, etc and you won't be able to find that, unless you're intercepting all traffic and can decrypt it (and apps nowadays love to pin certificates). This is imaginary attack, I have no idea whether whatsapp does that. But HTML is a powerful and dangerous beast, yet it's used a lot in applications for rich media.