And how does one verify that the public key received belongs to the intended party, rather than a mitm?
If the answer is blind trust in a third party that runs the messaging service then I suspect that you can guess what the people asking those questions are really asking.
Diffe-Hellman-Merkel key exchange is vulnerable to attacker-in-the-middle attacks.
Eave could just do key negotiation with Alice and separately do key negotiation with Bob. You have to use a slightly more complicated cryptographic protocol to avoid this issue.
How would the keys get stored in the user's private browsing window? Do they lose all chat history when they log in on a private browsing window and then close it?
I don't know the technical details of that for sure, but I think the answer is that keys and chat history are stored on-device only; for example you lose your WhatsApp history if you don't restore a backup when moving to a new phone.
If a messaging app is showing you message history in a private browsing window then perhaps the encryption key for that history is derived from your password or something like that; that can be done locally so that all the server ever sees is encrypted data.
What if you log into the app and then log out of the app and then log into the app again? Should you be able to see your messages?
E2EE is a fail-secure design. In case of any doubt it deletes your private messages. When applied to this case I don't think the downside of constantly losing all your messages outweighs the upside of Facebook pretending they don't have a copy of all of them.
Are you asking for technical details about E2EE in messaging apps, or simply making the point that you don't like it? If you don't like it, then fine, you do you, however I would point out that we all accept some inconvenience in our lives as a trade off for improved security; the lock on my front door is inconvenient but I'd rather have it than not.
As to whether or not Meta have been lying about it, then that would be on-brand for them, but then what are they turning off if so? Or maybe the whole thing is theatre, and I should better disconnect from the internet altogether? I don't see the value in speculating about that.
Not being able to receive messages except on one device isn't a minor inconvenience.
To fix this, you either need to authorize each device (and web browser) from another device that's logged in, or the central authority holds your keys.
I run WhatsApp concurrently on two phones and receive all messages on both devices. But generally speaking this is where we disagree - requiring all devices to be authorised by me is feature not a bug as far as I'm concerned.
> And how does one verify that the public key received belongs to the intended party, rather than a mitm?
Fingerprints. Again, this is like Crypto 101. Not saying that as a personal attack of any kind, I just remain incredulous that what used to be entry level knowledge in “our thing” has evidently become so obscure.
You shouldn't be talking down like this, you're wrong about it. Alice and Bob need to exchange keys beforehand in some trusted out-of-band way. There's no protocol that solves this if Eve can be in the middle. I'm not sure what you mean by fingerprints, but if you describe a protocol, I can describe the mitm attack.
Bob and Alice are setting up their e2e channel, and because they have some extra level of concern about snooping, they telephone each other and read off some form of hash of the public key to each other.
A more complex variant would be something like PGP implemented, where Bob and Alice could both sign each others keys after this exchange, ensuring that someone who hadn’t met Bob but did trust Alice could inherit trust in Bob’s Alice-signed key.
You’ve stated unequivocally that I’m wrong, so now, please show your homework.
This is a very frustrating exchange. You guys are saying the same thing. For key exchange to be secure against an attacker who can MITM the channel you're securing, either the public keys or at least their respective fingerprints need to be exchanged out of band, over some channel the same attacker cannot also MITM. For a sophisticated enough targeted attack, a telephone isn't that.
The way military radios handle this is hardware key loaders that have seeds pre-synced in factory, in person. Every day in the field, a unit comms person takes the key loader and loads new keys onto everyone's radios. The key loaders themselves are reseeded and resynced during maintenance periods between campaigns or exercises. They're physically accounted for on every movement and twice a day when not moving, and if they ever can't be found, all messages from any device they loaded keys onto is considered compromised.
Anyone trying to overthrow a government or run a criminal empire or whatever is going to have to take measures at least this drastic. Or quit LARPing and accept that nation state attackers can probably slide into your Instagram DMs, which are probably being sent to people you don't know, and if they're hot and actually answering you, 90% chance they're a honeypot anyway.
Web of trust or centralized trust are the main answers here.
Compromise of the secret key is a whole other issue - revocation.
MITM of a key can be solved pretty well via web of trust techniques.
Apologies if the dialog is frustrating to read! As a “recovering cypherpunk”, I find these sorts of discussions animating, as long as they’re polite and technically focused! Much love!
The London Mayor some years ago, Ken Livingstone, was a huge proponent of public trasport and used it extensively.
The current Mayor, whilst still a proponent, likely does not use it. A quick glance at the social media that he recieves will tell you why - it would not be safe. He needs to travel with close protection officers.
The reason? He is Muslim, and Britain has become a very racist country indeed. Well, maybe always was, but the likes of Farage and Musk have so emboldened them that there is no longer a stigma.
Can confirm. Made a bit of a leftfield suggestion for an issue that there were no truly good solutions proposed for. I was tasked with building and deploying it. It's in production and working well so far (service which is 90% of our egress bandwidth). Got some really nice feedback from the director of technology at the Christmas social event.
I can't imagine that it's hurt my job security, and it's been far more interesting than waiting for someone to find me busywork to do.
I can't think of many better ways to demonstrate to your colleagues and corporate overlords that you are worthy of their trust than to readily hold up your hands if you've screwed up.
So long as you're not so incompetent that you're repeatedly doing stupid stuff or cynically causing issues so that you can make yourself look virtuous by owning up, of course.
In corporate context, admitting exernally-facing liability too easily violates executives' fiduciary responsibility to shareholders. For incentives aligning, need to figure out how to unravel that beasty.
On the contrary, I think it can be sold as a PR win: Think about how many companies torch customer goodwill by making a bad decision and then doubling and tripling down on it for months (before backpedaling and losing a ton of customers anyways).
I don't know, but I'd hazard a guess: not many? Or rather, plenty do, but they don't lose much customers - any company worth their salt is positioned to screw over their users, unintentionally or otherwise, with little to no consequences to its business.
I've built a proof-of-concept WireGuard VPN for work (SSO with mTLD portal/OIDC, BGP/WG tunnels to link edge servers into the network) and the team love it - better than the Cisco VPN they'd have to use otherwise.
Only problem is the config - I'd love a simple alternate WG app (for macOS/Windows) that could pull a config from a remote endpoint (checking signing) and bring up a WG tunnel with the config presented.
I've written a Golang client which shows up in the macOS menu bar and handles all this, but it's using the Brew WireGuard command line tools and needs sudo, etc., etc., so it's not really suitable for the average user.
There are quite a few open source wg clients out there, maybe you can get some ideas from those. Defguard, netbird come to mind.
I just want to avoid all that custom client stuff.
I don't have a solution, but I was experimenting on having a unique network url that would show different content depending if you're hitting it via the wireguard connection or not. Pretty basic stuff, just firewall rules and nginx proxying. Add the (hub) endpoint to client's AllowedIPs and route traffic on the hub depending on the networ interface and port the traffic is coming from.
So the client would connect to the wg network and open up the network page (eg. home.rudasn.wirehub.org).
If the connection is established, they would see a welcome message or whatever (if they need to update their config maybe a link to get their new one).
If the connection is not via the wg tunnel, they would see a message to first connect to the wireguard vpn. And if it's their first time, directions on how to install the official client and get their config from their admin (via wirehub.org or whatnot).
It's nice to have that automated via a custom client, but I don't think it's such a huge issue - if you would only update configs for client devices sporadically and have the server peers polling for updates every x seconds.
The downside of custom client apps is another security layer to consider, which nobody has the time for.
If the answer is blind trust in a third party that runs the messaging service then I suspect that you can guess what the people asking those questions are really asking.
reply