4 ms·

I think the "end-to-end" statement is also misleading as you don't really know whether the communication is indeed encrypted end to end. If you want true end to

I think the "end-to-end" statement is also misleading as you don't really know whether the communication is indeed encrypted end to end. If you want true end to end ecryption you can grab a tool that will generate public and private key pair, send public key to your contact and ask them for their public key. Then use tool to encrypt your following messages with your private key and received messages with your contact's public key. Then it doesn't matter whether underlying transport is encrypted or not. Things like Whatsapp give false sense of security. I am pretty sure the messaging can be accessed but nobody will ever admit it. You can make it less obvious that you are sending encrypted messages by using two way binary to English text transcoder, so your messages will appear like an English conversation (although easy to pick as gibberish by a censor)

maxerickson 7y ago
It's entirely possible to examine the compiled app and understand whether it sends the private key or unencrypted messages off the device, there's no need to treat the behavior or Whatsapp like a mystery.
- dependenttypes 7y ago
  It is not as simple.
- upofadown 7y ago
  It is possible but extremely unlikely that anyone would ever bother to do this. Anyone that cared that much would just use something with source available and save themselves a whole lot of pointless effort that would have to be repeated every time a new binary was generated.
- varispeed 7y ago
  You don't know whether private key is generated in a way that could be replicated on the server and you don't know what is running on the other side.
- rndgermandude 7y ago
  The crux of the matter is verifying that the public key you're told is the public key of the other person, is actually the public key of the other person. If you do not verify this out-of-band, then the server can generate a new keypair for each recipient and it would go like this: - Alice encrypts message using FAKE public key of Bob (she was told is Bob's key by the server), sends it to whatseverapp server so it can be delivered to Bob when he sign on. - Whatseverapp server has FAKE private key for Bob (it generated that one itself, after all), decrypts message and notifies the corporate overlords/government/Russians/AdSevers/Illuminati of contents. - Whatseverapp server encrypt message using REAL public key of Bob, sends it to Bob - Bob decrypts the message using his REAL public key, reads it. This out-of-ban verification is nothing you can automate or do once-for-all, like analyzing the binary for bad stuff. Each user has to verify the key of the other users. Which very few people actually do. Also, you make it sound so easy to analyze an app binary. You can relatively easily prove it does certain things; but to prove a negative, namely that it does NOT do certain things is far more difficult at least and outright infeasible or even impossible in other cases (compare with halting problem). This is why security vulnerabilities happen, and a backdoor is more or less just a security vulnerability that didn't happen by accident or incompetence but deliberately - which may mean whoever put it there might have spent some time to obfuscate it even further to make it harder to find.

maxerickson 7y ago

It's entirely possible to examine the compiled app and understand whether it sends the private key or unencrypted messages off the device, there's no need to treat the behavior or Whatsapp like a mystery.

dependenttypes 7y ago
It is not as simple.
upofadown 7y ago
It is possible but extremely unlikely that anyone would ever bother to do this. Anyone that cared that much would just use something with source available and save themselves a whole lot of pointless effort that would have to be repeated every time a new binary was generated.
varispeed 7y ago
You don't know whether private key is generated in a way that could be replicated on the server and you don't know what is running on the other side.
rndgermandude 7y ago
The crux of the matter is verifying that the public key you're told is the public key of the other person, is actually the public key of the other person. If you do not verify this out-of-band, then the server can generate a new keypair for each recipient and it would go like this: - Alice encrypts message using FAKE public key of Bob (she was told is Bob's key by the server), sends it to whatseverapp server so it can be delivered to Bob when he sign on. - Whatseverapp server has FAKE private key for Bob (it generated that one itself, after all), decrypts message and notifies the corporate overlords/government/Russians/AdSevers/Illuminati of contents. - Whatseverapp server encrypt message using REAL public key of Bob, sends it to Bob - Bob decrypts the message using his REAL public key, reads it. This out-of-ban verification is nothing you can automate or do once-for-all, like analyzing the binary for bad stuff. Each user has to verify the key of the other users. Which very few people actually do. Also, you make it sound so easy to analyze an app binary. You can relatively easily prove it does certain things; but to prove a negative, namely that it does NOT do certain things is far more difficult at least and outright infeasible or even impossible in other cases (compare with halting problem). This is why security vulnerabilities happen, and a backdoor is more or less just a security vulnerability that didn't happen by accident or incompetence but deliberately - which may mean whoever put it there might have spent some time to obfuscate it even further to make it harder to find.