Thanks for all the great comments! Combining the responses:
I asssume when talking about design proposals, for secure comms, that always Android and iOS devices are used. Are people aware when using such devices, about zero-click exploits, from Pegasus (NSO Group, or FinFisher/FinSpy? I sold my smartphone exactly for that reason and switched to a dumb phone
exactly right. And the open source OS should be running on non-compromised hardware. Oh, wait.
That. In the real world, we can't all hand build and personally operate our own billion dollar fab to ensure atomic-level security of our entire vertical supply chain. And even if you could... who's to say the Feds don't sneak in and swap your device with a perfect duplicate when you aren't looking? Ultimately if you are trying to protect yourself from the combined might of, oh, 8 billion other people, you're going to have a tough time of it. I'm not building for that use case (nor is anyone else). I'm building for the billions of people who aren't trying to protect themselves from the Feds, but from other more common (even if more mundane) privacy threats.
https://www.nitrokey.com/news/2020/nitropad-secure-laptop-unique-tamper-detection
How do you know they aren't an NSA front? Ultimately, you can't. At some point you've got no choice but to trust someone.
It would make sense to contribute or work with a project like Signal rather than making a new messenger
Well my job is to secure the privacy of Expensify's millions of users, not just shut down shop and tell them to use Signal (especially since Signal doesn't offer the wide range of preaccounting functionality we do).
The only reasonable way to sell something on an app store is to distribute a binary. Meanwhile with the source available, people can build their own clients, and share them via other channels.
I totally agree, no real world system can grow if it presumes everyone builds their own binaries (and presumably inspects the source code personally to make sure nothing was slipped in via Github when pulling down the repo). My only point is real-world systems do not exist in a vacuum: the only way to realistically build a secure communication system used by billions is to rely upon trusting _the very people you don't want to monitor you_ to allow you to do so without interference. It's a harsh, brutal reality, but there it is.
I visited expensify.cash but didn't notice an obvious link to the source code. It can be hard for me to see things, though.
Ah, sorry! It's a new project so we're mostly focused on curating a small set of dedicated contributors before going too wide. But you can see it here:
https://github.com/Expensify/Expensify.cash -- Sign up at
https://Expensify.cash and enter your Github handle, and we'll invite you to the various testflights and such. We're also hiring freelancers to help out -- here are a bunch of open jobs, and we're adding more all the time:
Thank you so much for your open source work. Please work with existing open source projects when you can both benefit from the work, so the community can grow.
I 100% agree. We're major sponsors of SQLite, and have also open-sourced our BedrockDB.com, which was running a blockchain in production before it was cool:
https://bedrockdb.com/blockchain.html
Here is information on signal's reproducible builds:
https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds
You actually can verify that the app from the play store is the one you have the source to.
Whoa, that's neat! But doesn't change my point: unless everyone is doing this -- and doing it for every single upgrade -- it doesn't really matter. This is a neat parlor trick to create a sense of trust, but I think it's a kind of disingenuous performance of security theatre: that's like shining a spotlight on Trump's 20 mile border wall while ignoring that it's a very incomplete protection. Verifying the APK that you are getting from Google Play never actually makes sense:
1. If the feds *have* identified your device AND you are a sufficiently interesting person of interest that they would force Google to ship you a compromised APK -- they could also just force Google to ship you a compromised, invisibly-installed system update. Verifying the APK doesn't prove anything.
2. If the feds *have not* identified your device, or you are NOT sufficiently interesting to warrant being compromised, then verifying the APK won't ever find anything.
Whether you are or are not a target, if you are installing Signal via Google Play, you sorta have no choice but to assume that Signal and Google haven't been compromised: if you believe that, then there's no need to verify. But if you do NOT believe that, then verifying it isn't nearly enough. (Especially when no amount of securing your own device will secure the device of the person you are talking to -- who if you are a target, is probably also a target, or at least you shouldn't assume they aren't.)
Current public-key systems have severe limitations in message size, so symmetric key systems make the public-key algorithms far more useful.
Hm, but all encryption has severe limitations in message size -- even symmetric encryption works on relatively small block sizes. This is why the input is split up and something like CBC is used to prevent "known-plaintext" attacks, with each CBC block separately encrypted with the symmetric key.
What I'm trying to figure out is why people don't use something like CBC directly on top of public key encryption. Again, I can see the performance advantages of using symmetric keys, but I'm not sure if there is any actual security advantage between:
a. Use DH to generate a symmetric key X from my private key (A.priv) and your public key (B.pub), split input into N blocks, CBC encode and encrypt each block separately with that symmetric key
b. split input into N blocks, CBC encode and encrypt each block separately with your public key (B.pub)
In other words, block-cipher modes are designed to protect against small biases in the ciphertext itself, which is a round-about way of saying you probably don't want to attempt what you are suggesting.
Can you elaborate on what you mean by this? I'm sorry, I'm not quite following it.
Thank you all for your help, I really appreciate it!
-david