[DexesTTP]

"Intrinsically linked" doesn't exist. Encryption is math, math you can do on a piece of paper (in theory). Anything you set up to log the fact that people did that math is always going to be meaningless if people take the numbers and do the math away from your logging system.

Now, you can say "but you can't ever access the numbers, just order the computer to do the operation". And also "To order the operation, you need 2FA and a signature for a judge and the president". And, of course, "The numbers needed for decrypting are split between three different servers all with their own security system and they can't be forced to talk to each other without the president's signature being added to a public log". And that's all well and good, but consider this: I install a listener on the RAM of each of the three servers. I wait until it does a totally legit, totally approved thing that gets logged. I now have the numbers copied somewhere. I do the decrypting for everything else away from the servers.

Sounds like a difficult operation? You're talking about three numbers worth a trillion dollars if they ever get out. Spy missions have been done that were harder to pull off for less benefit.

You just thought of [technical solution] to prevent listening through the RAM? Great, you just solved one _very obvious_ part of the attack surface. Now to address the ten thousand other parts identified by your threat model, and I really hope that you did a perfect job while designing that threat model because one blind spot = all of the keys are out forever. Also, no pressure, but your team of 10 or 100 or even 1000 people working on that threat model are immediately going to be pit against teams of the same size from every government ever, so I hope your team has the best and most amazing engineers we'll ever see in the world. And that's not considering the human aspect of all of that, because, well, one mole during the deployment, one developer paid enough by an adversary to do an "accidental" typo that leaves a security hole, one piece of open-source software getting supply chain attacked during deployment, and your threat model is moot.

[ethbr1]

So many arguments against this boil down to 'Anything less than perfection isn't perfect.'

That true.

But it's also missing goods of a less-than-perfect but better-than-worst-case system.

By your argument, TLS shouldn't exist.

And yet, it does, is widely deployed, and has generally improved the wire-security of the internet as a whole. Even while having organizational and threat surface flaws.

I agree with you that no government entity should have decryption keys in their possession.

However, I disagree that there should be no way for them to force decryption.

There's technical space between those two statements that preserves user privacy while also allowing the legal systems of our society to function in a post-widespread personal encryption age.

[DexesTTP]

That's completely missing the point. This is not about perfection, this is about the threat level.

Decryption is always going to be technically possible. A government can always get possession of a phone, invest a lot of time and skill to get the key out of it, and then use that. This is what happened in that one famous Apple case, and this is what is always going to happen when people use E2E encryption. The point I made in my other posts was that once you get the key, you have the key, and that doesn't change just because the key is on the phone. That's your threat model when you use E2E encryption.

TLS works the same way. The encryption keys are ephemeral, but they're temporarily stored on your computer and on the server you're communicating with. If you want to attack a TLS connection (and you can!) you need to obtain the key from either the server or the client, and that's your threat model when you use TLS.

This is a completely fine and acceptable threat model as long as the keys are stored in a disparate sea of targets, either on hundred of millions of possible client/server machines for TLS, or on each person's phone (each one with a different model, from a different maker, and using different apps) for E2E. The thing is, in such a distributed model, nobody can realistically get every key out of every phone at once. This makes every single attack targeted to a couple of high-profile target, and therefore the impact of successful attacks way, wayyyy lower.

The issue arises when you decide to forbid end-to-end encryption, and instead mandate a global way to decrypt everything without needing access to the phone itself. This changes the threat model in a way that makes it unsustainable.

Again, and I know I repeated that vault analogy but it's a great way to explain attack surfaces and threat models: It's fine if everyone has a vault at home with their life savings in gold inside, because nobody can realistically rob every vault from everyone at once. It's still fine if every city has a vault where people store their gold, because while a few robberies might happen, it's possible to have high enough security to make it not worth to rob this vault. It starts being a bad idea to ask everyone to put their gold into a large, unique central vault that "only the government" has access to, because the money you need to spend to protect that vault is going to be prohibitive (and no way the government isn't going to skimp out on that at some point). And finally, it's an awful ideal to make that with magical gold that you can steal by touching it with a finger and teleporting out with it, because all of that gold is going to disappear so fast you better not blink, and losing that combined pile gold is going to impact every citizen ever.

It's a matter of threat modeling: the moment there's a way to access absolutely everything from a single entry point with possibly avoidable consequences for the attacker, then that entry point becomes so enticing that you can't protect it. You just can't. No amount of effort, money, and technical know-how is going to protect that target.

[ethbr1]

> TLS works the same way.

TLS does not use emphemeral keys, from a practical live connection perspective, because the root of trust is established via chaining up to a trusted root key.

Ergo, there are a set of root keys that, if compromised, topple the entire house of cards by enabling masquerading as the endpoint and proxying requests to it.

And that's exactly the problem you're gripping about with regards to a tap system. One key to rule them all.

[DexesTTP]

Hacking the root certificates of TLS doesn't allow you to read every TLS-encrypted conversation ever, thankfully. It just allows you to set up a MITM attack that looks legit. And sure, that is bad, but it's not "immediately makes everything readable" bad.

That's why I call TLS keys "ephemeral" under this threat model.

The goal of anti-E2E legislation isn't to be able to MITM a conversation - again, government agencies can already set that up with the current protocols fairly easily. The goal of the legislation is to make it so that, "with the correct keys that only the good guys have", you can decrypt any past message you want that was already sent using the messaging system, without needing access to either device.

If the governments only settled with an "active tap system" that works like a MITM for e2e encrypted channels, we wouldn't be having this discussion or we wouldn't be talking about new regulations. Because again, that is already possible, and governments are already doing it.

[ethbr1]

That's why I put the live caveat. Granted, decryption of previously recorded conversations and decryption of new conversations are two different threat models.

Out of curiosity, can MITM of new connections be set up fairly easily with current protocols? (let's say TLS / web cert PKI and Telegram)

For the TLS case, they'd need to forge a cert for the other end and serve it to a targeted user. Anything broader would risk being picked up by cert transparency logs. Which limits the attack capability to targeted, small-scale and requires control of key internet routing infrastructure? Not ideal, but at least we're limiting mass continuous surveillance.

For Telegram, the initiation is via DH [0] and rekeyed every 100 messages or calendar week, whichever comes first, with interactive key visualization on the initial key exchange [1]. That seems a lot harder to break.

[0] https://core.telegram.org/api/end-to-end

[1] https://core.telegram.org/api/end-to-end/pfs#key-visualizati...

[EGreg]

And not just TLS and certificate authorities but also DNSSEC. Still, it is pretty worrying to have one CA like letsencrypt be behind so many sites, or seven people behind DNSSEC:

https://www.icann.org/en/blogs/details/the-problem-with-the-...

But here is how they protect it:

https://www.iana.org/dnssec/ceremonies

On the other hand, data is routinely stored in centralized databases and they are constantly hacked:

https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says...