[fc417fc802]

> E2EE means only your intended recipients can access the plaintext.

No, it does not. It means that only endpoints - not intermediaries - handle plaintext. It says nothing about who those endpoints are or who the software is working for.

Key escrow and E2EE are fully compatible.

[barsonme]

No, it is not. This is precisely why we have the term E2EE. An escrow agent having your keys but pinky promising not to touch them is indistinguishable from the escrow agent simply having your plaintext.

Unless you’re fine with the escrow agent and anybody they’re willing to share the keys with being a member of your group chat, in which case my original point still stands.

[fc417fc802]

Edit: I think you might be confusing your personal intention (ie I wanted this to be private but didn't realize the service provider retained a copy of the keys) with the intention of the protocol (ie what the system is designed to send where). Key escrow is "by design" whereas E2EE protects against both system intrusions (very much not by design) as well as things like bugs in server software or human error when handling data.

> is indistinguishable

Technically correct (with respect to the escrow agent specifically) but rather misleading. With E2EE intermediary nodes serving or routing a request do not have access to it. This protects you against compromise of those systems. That's the point of E2EE - only authorized endpoints have access.

The entire point of key escrow is that the escrow agent is authorized. So, yes, the escrow agent has access to your stuff. That doesn't somehow make it "not E2EE". The point of E2EE is that you don't have to trust the infra. You do of course have to trust anyone who has the keys, which includes any escrow agents.

If we used the definition "only your intended recipients can access the plaintext" ... well let's be clear here, an escrow agent is very much an "intended recipient", so there's no issue.

But lets extrapolate that definition. That would make E2EE a property of the session rather than the implementation. For example if my device is compromised and my (E2EE) chat history leaks suddenly that history would no longer be considered E2EE ... even though the software and protocol haven't changed. It's utterly nonsensical.

[KronisLV]

> I think you might be confusing your personal intention with the intention of the protocol

So what would be the name for a mechanism where escrow is deliberately not a part of the design and nobody aside from the sender and recipient can access the plaintext data, no 3rd parties whatsoever, as long as those two participants aren’t compromised.

I’m not disagreeing with you but I’ve heard people talk about E2EE while actually thinking it’s more like the above. There is probably a term for truly private communication but I’m sleepy and it eludes me.

[fc417fc802]

The literal answer to your question would be "E2EE without key escrow" I guess. Or E2EE between just me and this single party.

However I don't think that's so much a technical mechanism as it is a statement of preference or understanding about who you intend to have access to something.

To that end, you'll need to define "intended recipient" pretty carefully. After all, your intended recipient could take a screenshot and share it. Or there could be someone in a group chat who isn't participating and you forgot was there. Etc.

> There is probably a term for truly private communication

I'd argue that E2EE is "truly private" between the intended recipients, and that understanding who exactly those are is entirely the responsibility of the user.

Of course I recognize that we're talking past each other at that point. Your concern seems to be users not realizing an escrow agent is present. To the extent they might have been deceived about the implementation I'd point out that "snuck in an escrow agent" is just the tip of the security iceberg. They could also have been deceived about the implementation itself. And even if they weren't deceived initially, a binary or web app could be intentionally updated with a malicious version. Does it count as "truly private" if you didn't compile it yourself?

[KronisLV]

> Of course I recognize that we're talking past each other at that point. Your concern seems to be users not realizing an escrow agent is present. To the extent they might have been deceived about the implementation I'd point out that "snuck in an escrow agent" is just the tip of the security iceberg. They could also have been deceived about the implementation itself. And even if they weren't deceived initially, a binary or web app could be intentionally updated with a malicious version. Does it count as "truly private" if you didn't compile it yourself?

All of these are good points, thanks for taking the time to respond! I think that to a certain degree this means that, for the average layperson and someone with more skills and knowledge, there are still a bunch of challenges and attack vectors to contend with.

It probably involves more of something in the category of OpenPGP (or just Signal, I guess) where you yourselves are in control of the keys, and less of counting on various web apps to do right by the users. That said, E2EE with escrow is still helpful against certain risks and is a net positive, even if I've seen a lot of that misunderstanding about what it actually does.

[fc417fc802]

No problem! The more people conscious of this stuff the better off we all are in the long run.

Anything that you can either audit or compile yourself is generally a good bet. You might add Matrix, XMPP with OMEMO, Briar, and Cwtch to your list.

Proprietary stuff isn't an entirely bad deal though. If you assume they aren't blatantly fraudulent then presumably your data is better protected than it would have been without even an attempt at E2EE.

Same for key escrow schemes. Even if the agent was literally the NSA you'd still most likely be better off than the much more vulnerable alternative. The fewer entities with access and the more deliberate that access is the better.

[zxcvgm]

Well, WhatsApp backups claim they are E2E encrypted, but there’s a flow that uses their HSM for the encryption key, which still feels like some escrow system.

https://engineering.fb.com/2021/09/10/security/whatsapp-e2ee...

[wkat4242]

True but you can choose to store the key completely yourself. That fixes a big backdoor that's been around for ages.

The biggest problem remaining to me is that you don't chat alone. You're always chatting with one or more people. Right now there's no way of knowing how they handle their backups and thus the complete history of your chats with them.

It's the same thing as trying to avoid big tech reading your emails by setting up your own mailserver. Technically you can do it but in practice it's pointless because 95% of your emails go to users of Microsoft or Google anyway these days.

[prophesi]

> Key escrow and E2EE are fully compatible.

Wild to see someone on HN even entertain this idea.

[fc417fc802]

It's literally the point of key escrow. My views on a given practice are entirely irrelevant to the definition of the relevant terminology.

[prophesi]

With key escrow, by definition you can only implement end-to-many-ends encryption.

[fc417fc802]

TIL group chats can't be considered E2EE. /s

[prophesi]

Those would be end-to-end encrypted x how many recipients you intend for. Very different from (end-to-end-encrypted x how many recipients you intend for) + an arbitrary amount of recipients you don't intend for.

[fc417fc802]

> an arbitrary amount

Presumably there are a finite number of escrow agents who are known to you. Worrying that they will pass your messages along to others is the same as worrying that the people you're chatting with do the same. It's always on you to assess the trustworthiness of the other parties; key escrow is no exception to that.

To be clear I'm not a fan of large scale key escrow schemes and am not going to willingly use one outside of a corporate setting. But lets have accurate use of terminology while discussing these things.

Surely a company with auditing requirements running their own key escrow would still be considered E2EE? If not E2EE then what would you suppose to call that and where would you draw the line?

[baq]

Wild to think otherwise.

[prophesi]

Glad to hear your alternative solutions! Though going by your comment history I doubt that will occur.