3 ms·

It's not hard to demonstrate that apps are performing end-to-end encryption even if you don't have access to the source code. Reverse engineering this stuff is

by mjg59 10y ago

It's not hard to demonstrate that apps are performing end-to-end encryption even if you don't have access to the source code. Reverse engineering this stuff is really pretty straightforward.

dingaling 10y ago
It's not just that they're performing encryption, but also assurance that (1) they're using the keys they declare and (2) they aren't sending other data over unannounced side-channels. You can't just insert yourself in the message stream since the client and server use pinned, mutual certificate authentication. So you have to start from first-principles and step through decompiled code.
- mjg59 10y ago
  > they're using the keys they declare I'm not sure what you mean here. It's easy to identify where the key comes from and whether the ciphertext is what you'd expect it to be in that case. > they aren't sending other data over unannounced side-channels. It's not straightforward to determine that even if you do have the source - you could imagine an implementation that deliberately leaks information through timing details without that being obvious from the code. At some point you have to trust that authors aren't doing something awful. > So you have to start from first-principles and step through decompiled code. Well no, because the first thing you can do there is just disable certificate pinning. But really, the difficulty of stepping through decompiled code is vastly overrated.
- fidget 10y ago
  Unannounced side channels seems like by far the easiest thing to deal with there; send a 2mb file, observe network patterns, raise an eyebrow if 2mb gets sent over a channel that you didn't expect. As for using the correct key, dismantle the signal message envelope until you get your blob of encrypted message. Then see if the same blob appears on the target device. Multiple keys? I imagine either correlating message size and network traffic (encrypting stuff twice could well show up), or going at it with a debugger. Which is really the answer to all of these questions instead of any network shenanigans. You root your phone and attach a debugger, then step through what signal is doing. Not a security researcher, never reverse engineered anything for security reasons in my life.
  - snovv_crash 10y ago
    What if it only does it at a much later point in time, or slowly via adding data to other comms channels? What if it only does it for small payloads by padding packet sizes to 1k? There are so many ways to get around this, unless we have open source and reproducible builds.
    - fidget 10y ago
      Right, which is why I said those blackbox methods were pretty rubbish. You step through it with a debugger.
      - ThrustVectoring 10y ago
        The point isn't to nab every thought-to-be-encrypted conversation on Signal. The point is to evade detection while compromising high-value message streams. Stepping through with a debugger is never going to execute the feature-flagged "pwned" mode.
  - jimmies 10y ago
    >Unannounced side channels seems like by far the easiest thing to deal with there; send a 2mb file, observe network patterns, raise an eyebrow if 2mb gets sent over a channel that you didn't expect. Facebook distributes your 2MB pic to many people, does it technically require more than 2MB of your upload bandwidth? No. You only need to upload it once to their server.
- 7952 10y ago
  This is actually an area where web apps have some advantage. You can inspect the network traffic using developer tools. You have cross domain rules that restrict traffic. And the encryption is performed by the browser rather than in the apps black box.
- 7952 10y ago
  This is actually an area where web apps have some advantage. You can inspect the network traffic using developer tools. You have cross domain rules that restrict traffic. And the encryption is performed by the browser rather than in the apps black box.
- ynezz 10y ago
  You can do whatever you want with your system, if you've complete control. So even pinned certificates are not a big deal. You can read the messages unencrypted or you can remove the certificate checking in the code for example.
imaginenore 10y ago
It's much harder to demonstrate the app doesn't have a backdoor, or doesn't leak your data in some obscure way, or doesn't weaken the entropy when creating the keys.
whycombo1 10y ago
While you can verify that the software is in fact encrypting the data and not sending anything it should not send, you can never know who has access to the encryption keys. They are created by WhatsApp, who knows how and where they store them and who can access them.

by mjg59 10y ago

It's not hard to demonstrate that apps are performing end-to-end encryption even if you don't have access to the source code. Reverse engineering this stuff is really pretty straightforward.

dingaling 10y ago

It's not just that they're performing encryption, but also assurance that (1) they're using the keys they declare and (2) they aren't sending other data over unannounced side-channels. You can't just insert yourself in the message stream since the client and server use pinned, mutual certificate authentication. So you have to start from first-principles and step through decompiled code.

mjg59 10y ago
> they're using the keys they declare I'm not sure what you mean here. It's easy to identify where the key comes from and whether the ciphertext is what you'd expect it to be in that case. > they aren't sending other data over unannounced side-channels. It's not straightforward to determine that even if you do have the source - you could imagine an implementation that deliberately leaks information through timing details without that being obvious from the code. At some point you have to trust that authors aren't doing something awful. > So you have to start from first-principles and step through decompiled code. Well no, because the first thing you can do there is just disable certificate pinning. But really, the difficulty of stepping through decompiled code is vastly overrated.
fidget 10y ago
Unannounced side channels seems like by far the easiest thing to deal with there; send a 2mb file, observe network patterns, raise an eyebrow if 2mb gets sent over a channel that you didn't expect. As for using the correct key, dismantle the signal message envelope until you get your blob of encrypted message. Then see if the same blob appears on the target device. Multiple keys? I imagine either correlating message size and network traffic (encrypting stuff twice could well show up), or going at it with a debugger. Which is really the answer to all of these questions instead of any network shenanigans. You root your phone and attach a debugger, then step through what signal is doing. Not a security researcher, never reverse engineered anything for security reasons in my life.
- snovv_crash 10y ago
  What if it only does it at a much later point in time, or slowly via adding data to other comms channels? What if it only does it for small payloads by padding packet sizes to 1k? There are so many ways to get around this, unless we have open source and reproducible builds.
  - fidget 10y ago
    Right, which is why I said those blackbox methods were pretty rubbish. You step through it with a debugger.
    - ThrustVectoring 10y ago
      The point isn't to nab every thought-to-be-encrypted conversation on Signal. The point is to evade detection while compromising high-value message streams. Stepping through with a debugger is never going to execute the feature-flagged "pwned" mode.
- jimmies 10y ago
  >Unannounced side channels seems like by far the easiest thing to deal with there; send a 2mb file, observe network patterns, raise an eyebrow if 2mb gets sent over a channel that you didn't expect. Facebook distributes your 2MB pic to many people, does it technically require more than 2MB of your upload bandwidth? No. You only need to upload it once to their server.
7952 10y ago
This is actually an area where web apps have some advantage. You can inspect the network traffic using developer tools. You have cross domain rules that restrict traffic. And the encryption is performed by the browser rather than in the apps black box.
7952 10y ago
This is actually an area where web apps have some advantage. You can inspect the network traffic using developer tools. You have cross domain rules that restrict traffic. And the encryption is performed by the browser rather than in the apps black box.
ynezz 10y ago
You can do whatever you want with your system, if you've complete control. So even pinned certificates are not a big deal. You can read the messages unencrypted or you can remove the certificate checking in the code for example.

imaginenore 10y ago

It's much harder to demonstrate the app doesn't have a backdoor, or doesn't leak your data in some obscure way, or doesn't weaken the entropy when creating the keys.

whycombo1 10y ago

While you can verify that the software is in fact encrypting the data and not sending anything it should not send, you can never know who has access to the encryption keys. They are created by WhatsApp, who knows how and where they store them and who can access them.