Live data from Hacker News

Meta Shuts Down End-to-End Encryption for Instagram Messaging

pcmag.com

181–190 of 235 posts

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#181

Earlier quoted context omitted.

> 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.

You’re not sure what key fingerprints are?

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.

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#182
post #161

Centralized proprietary software on on proprietary platforms can always be opted into a special update that makes all the private keys deterministic making end to end encryption useless for anyone with knowledge of that targeted backdoor. Only FOSS can deliver verifiable E2EE, and all centralized and proprietary solutions like Zoom, Whatsapp, Instagram, etc should end the security theater. I applaud Meta for at least…

Centralized FOSS software can do the same thing and remove encryption. Open source is not a requirement for security.

FOSS is however a prerequisite to Kerckhoff's principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#183

Earlier quoted context omitted.

The answer to most everyone question you’re asking is just, “public key cryptography”. It’s kind of disheartening to me that such basic 1990s tech as implemented by Phil Zimmerman is now obscure enough to merit questions like this. Both parties exchange public keys through the central service. Only the possessor of the respective (on device, Secure Enclave ideally) private keys can decrypt the messages encrypted to t…

No, it's not at all this simple. This is why so many "e2ee" apps like Telegram are bogus, they ended up prioritizing UX over security because there are many places where you can't pick both.

Webs of trust based on OOB key verification and signing, or centralized trust authorities are the two primary models I’m aware of.

I’ve always been enamored of the idea of DNS as a back end protocol to enable the former largely decentralized solution.

Bob looks up Alice and receives her key from Alice’s namespace within the DNS hierarchy, along with her trust claims. David then looks up Alice’s key within her namespace, sees a reference to endorsement by Bob, and can validate this by querying Bob’s namespace. David can also issue non-authoritative queries about Alice’s key to Bob’s DNS servers, ensuring that there is no mismatch between the query response received by Bob and the one received by David.

If Mallory manages to compromise Alice’s DNS, but not Bob’s, the result is a mismatch in query responses that both Bob and David can thus detect.

At scale, a MITM compromising a system like this would be difficult without compromise of a large number of independent namespaces, increasing the likelihood of detection via the non-authoritative queries.

The missing component in this arrangement is cryptographic security of DNS, which I cynically suspect is why the DNSsec working group was comprised of the usual suspects and eventually produced a protocol without query encryption. It could still be layered on by a protocol extension, however.

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#184

Earlier quoted context omitted.

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.

You’re not sure what key fingerprints are? 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 me…

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.

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#185

People here like it, but end-to-end encryption is an objectively worse user experience for people that don't care about that feature

I would argue that WhatsApp's e2ee user experience is pretty decent, and didn't get worse when they introduced encryption.

But then again, their technical model has always been "fat client, dumb server" from the start.

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#186

Earlier quoted context omitted.

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.

The only way to avoid this issue is if Alice and Bob can talk out-of-band. There's no protocol that fixes this.

True but the out of band secure channel could just be something like DNS, automated and constantly subject to distributed monitoring for deltas.

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#187
post #175

Earlier quoted context omitted.

Unlike the proprietary stuff there isn't a strong built incentive to remove it.

One incentive is that it makes for a simpler user experience.

It's absurd that you're actually taking the position you are

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#188

Earlier quoted context omitted.

You’re not sure what key fingerprints are? 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 me…

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 thi…

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!

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#189

Earlier quoted context omitted.

People, or at least Americans, didn’t care in 2012 when the Snowden reveal happened. We’ve been at that point for over a decade now.

Considering the average person thinks that opening websites in incognito means no one knows they visited them, I would agree.

"Be wary of malicious software that tracks your keystrokes in exchange for free smileys"

Re: Meta Shuts Down End-to-End Encryption for Instagram Messaging

#190

> 'Very few people were opting in to end-to-end encrypted messaging in DMs,' Meta says. Then why didn't you make the opt-in default like Signal and WhatsApp? :-)

Because either you have:

1. An E2E system where the provider has de facto access to the encrypted data, or

2. You shift key management to the users and let them risk data loss.

Either way:

a. The provider can release an app version at any time that accesses the data on the client side, and

b. Most of your users cannot differentiate between E2EE and SSL/TLS, nor are they interested in doing so, nor they care about it.

Post reply on HN