31–40 of 78 posts
Earlier quoted context omitted.
This is called "Reproducible Builds". https://signal.org/blog/reproducible-android/
Reproducible builds are for developers. As a user I didn't build the app on my phone. I have a phone with Signal on it. Tell me what I should do to verify it's running the open source Signal code.
As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages? Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a pa…
My employer rolled out a smartcard based PKI about 15 years ago, where you may own more than one card (optionally in sim card size for usb tokens) so, for example, you can have one in the office and have another one in your home office. Works quite well (modulo mobile) for now abour 30K employees. And, combined with RFID on the cards, you can call elevators, open doors, pay for food, etc.
Now if hardware manufacturers had standardized on appropriate hardware (chassis, keyboards, smart devices…) some 20 years ago, instead of trying (and failing) all kinds of software "solutions" … and thinner and thinner hardware, so no such cards or sticks would fit anymore …
As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages? Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a pa…
Not neccessarily, that just happens with bad implementations (i.e. most of them, sigh).
If you get a confidential letter in the physicsl world, you open it, read it, and then store it in a safe,.or a locked drawer, correct?
The software world chose to "re-seal" the letter in its envelope again instead. So if you loose your key, you loose access to the letter. The proper way to implement this would be to store the decrypted contents in the software equivalent of a lockable drawer, e.g. an encryped disk, folder or whatever. Which could (and should) have sensible fallbacks to retrieve its content.
How do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled? What if someone changed the open source before shipping it to the app store?
If someone with skills X (where depending on your knowledge and precautions, X can range from script kiddie to nation state) is after you specifically, you can only make their job harder, but unless you are very serious about security, you’ll probably get pwned.
If you want general security, you can probably take it as given that someone checked the Signal build to be the one that the source is available for, and that no one intercepted just your download. But you still have to take some parts on faith, always, unless you build your own CPU and continue from there.
How do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled? What if someone changed the open source before shipping it to the app store?
How do you know that the AES instruction set on your device's processor doesn't include a backdoor? Sure, the algorithm is public, but how do you know how it was implemented?
Briar Project appear to be a good E2EE messaging app. https://briarproject.org/how-it-works/
Remember when Zoom claimed that meetings were E2EE yet you could join the meeting by phone and no one batted an eye for at least one or two years? Noticed how no regular person cares when the "security code" of a chat partner changes in WhatsApp or Signal? Not to mention no regular person uses self-compiled apps for that, even if it were possible. E2EE is close to becoming a cargo cult, because done properly key mana…
How do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled? What if someone changed the open source before shipping it to the app store?
This is called "Reproducible Builds". https://signal.org/blog/reproducible-android/
> the Signal Android codebase includes some native shared libraries that we employ for voice calls (WebRTC, etc). At the time this native code was added, there was no Gradle NDK support yet, so the shared libraries aren’t compiled with the project build.
Also, assuming you trust the client, how to tell if the Signal server is running the published code, especially given Signal's track record of (not) publishing its source code?
https://linuxreviews.org/Signal_Appears_To_Have_Abandoned_Th...
How do you know if the Signal client running on your phone right now doesn't include a backdoor? Sure it's open source. But how do you know how it was compiled? What if someone changed the open source before shipping it to the app store?
As I understand it, if we had true end-to-end encryption, I would have to make sure I kept a set of keys, copied them between every computer and phone I used for chatting, and if I lost those keys I'd lose all my messages? Honestly, for most people I don't think that's functionality they would want, at least without us getting much better at interfaces and usability. Standard ways of storing keys, for example in a pa…
You often hear advice that comes down to keeping, say, your PGP keys in one secure place, but that is a terrible idea... E2EE encryption needs a good backup approach. If your system does not provide that in a easy to use way for the user then you have a bad system. E2EE encryption is hard but it doesn't help to leave all the hardness for the user.