NSA F9T53 Opsec Special Bulletin: Signal Vulnerability
scribd.com
scribd.com
https://www.soc.mil/IdM/publications/docs/general/Id_Privacy...
https://web.archive.org/web/20250308170611/https://www.soc.m...
If you don't link devices and check there are no linked devices your side of things is OK but you have no certainty in group chats or the other side one on one. So it's down to your own trust in the other party/parties.
"Two can keep a secret if one of them is dead"
EDIT: I'm using a fork, which may be why I'm seeing it and others aren't. See below.
However, it shows that the data is being provided to the client by the server, in some way. This is a guess, but it may be because sending clients have to encrypt with a key for each device.
Here's the code:
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
https://github.com/mollyim/mollyim-android/blob/26403ab1806a...
This "social engineering" hack? is simply allowing a 3rd party to gain access to another persons account and "snoop" on their secured messages/calls.
Pls correct me if I'm reading this wrong.
However, I think there is a real possibility that the Signal code (of which the public appstore versions are NOT fully open-source) could be modified to save/transfer messages after they have been decrypted, basically circumventing the whole point of e2ee... which is why having control over the client code is essential.
I suggest either building Signal yourself, using only verified reproducible builds without any binary blobs, or switching to the Molly-FOSS fork.