(C) Alec Muffett's DropSafe blog.
Author Name: Alec Muffett
This story was originally published on allecmuffett.com. [1]
License: CC-BY-SA 3.0.[2]


What do we mean by a “backdoor” in End-To-End Encrypted Messengers or Secure Messengers? #endToEndEncryption #e2ee

2021-03-01 17:52:10+00:00

UPDATE: 2021-05-05 – this blogpost has been simplified, tightened up, and redrafted with the intention of submitting it as an Internet Draft. The new text is hosted on Github.

I have been sitting on a half-finished essay about “backdoors in end to end encryption” for several months now, and it seems like the best way to get me to finish it is for me to leak the punchline, here and now. So: this is what I mean by “a backdoor in end-to-end secure messaging”.

End-To-End Secure Messaging

We fully define “End-To-End Secure Messaging” as messaging which satisfies five principles:

equality principle all participants are peers and have equal access to plaintext transparency principle the existence of all participants is/are visible to all other participants integrity principle the plaintext of any given message is only visible to the set of participants {at the time when, from & to whom} it was sent exclusionary principle non-participants have no access to plaintext, nor may they obtain information about plaintext content closure principle the set of participants in a conversation — those who will receive future messages — may not be increased except by intentional action of one/more existing participants

Why frame the definition this way?

we must describe “End-To-End Secure Messaging” rather than End-to-End-Encrypted Messaging in order to explicitly include peer-to-peer clients such as Ricochet which leverage Tor to supply encryption; other details of cryptography (algorithms, perfect forwardness, etc) are distractions to this discussion we must require all the participants to be peers who have equal access to plaintext, to differentiate the architecturally peer-to-peer “Ricochet” from client-server solutions such as “running IRC over HTTPS/Tor/the darkweb”, where the IRC operators might be participants but would also have unequal, privileged access to manipulate plaintext content this definition permits escrow mechanisms where they are implemented as a “known participant” — i.e. where all parties are aware of the escrow participant and mechanism for clarity: participants may include non-human “bots” for purposes of escrow, auto-welcoming, or FAQ auto-responders, etc; this is an implementation detail so long as they are bound by the same conditions as human participants.

Why pursue this definition?

Other attempts to define “backdoor” tend to get bogged-down in matters of “mens rea“: whether the mechanisms are intentional or not-intentional, or exist for purposes of regulatory compliance — yet may/may-not be enabled from one occasion to another — or perhaps were created for “developer convenience“, or perhaps were not intended at all.

This definition therefore attempts to frame “backdoors” in terms of outcomes, with respect to the participants in a conversation, versus “everyone else” — i.e. the non-participants.

So, what’s a “backdoor”?

From this, a “backdoor” in an end-to-end secure messenger is any mechanism where 1 bit of information about plaintext message content can become available to a non-participant without the intentional action of a participant.

This definition of a “backdoor” includes non-visible escrow, non-visible “ghosts“, client-side filters which actively or passively report “fingerprints” of plaintext content, etc.

The definition captures mechanisms where user-enrolment might include provisioning of message encryption keys that are weakened or escrowed/copied to third parties, as this, too, enables 1+ bits of data to leak to non-participants.

The definition permits participants to intentionally extend their access to other devices, e.g. via WhatsApp-for-Web. Equally: if a participant backs up all plaintext conversation to cloud storage, or if their platform is hacked, infected with platform malware or a remote-access trojan, or if the user enables or uses a feature that leaks message plaintext to systems beyond those that they control and trust, well, “oops” — that’s not a backdoor, that’s participant error.

The definition does not consider “message transport metadata” — size, time of sending, sender/recipient IP addresses, etc — to be part of a backdoor. The fact that the source, destination, or size of a message is visible to network observers is not a backdoor, because it’s an unavoidable consequence of network surveillance. However: that the client may expose the exact size of the plaintext, is likely a bug.

Are “bugs” backdoors?

They may be unintentional backdoors, yes. Or intentional.

Because this definition does not measure intent, there is no distinction of that, here.

To be a backdoor, it must simply satisfy the “what’s a backdoor” definition.

What does “1 bit of information” mean?

Examples of “1 bit of information about plaintext content” would include “the [fingerprint of the] message content does/does-not match [a fingerprint amongst those of] a given set of known message contents“, for instance:

“the document that the user shared was amongst those leaked by Edward Snowden”

leaked by Edward Snowden” “the document that the user shared was not amongst those leaked by Edward Snowden”

It could also mean that all or some part of the message content became known.

Why 1 bit?

Because 1 bit is the minimum amount of data that could be meaningfully “leaked” by a “backdoor” regarding plaintext message content; any number of bits-or-bytes greater than that would lead to discussions of “intent” or “utility”, and this definition does not deal with either of those subjective matters.

What does equal access to plaintext, mean?

The “equal access to plaintext” clause exists to highlight that in an end-to-end secure conversation, no participant is privileged with respect to accessing another’s content. This permits community moderation, but not exceptional content access.

Without the “equal access to plaintext” clause, plain old Facebook Messenger would be end-to-end secure by the above definition: Facebook could advertise itself as an escrow “participant” and yet would also have “godlike” raw database access to plaintext, as a non-participant, via means outside of the messenger software and conversation context.

This is by contrast to end-to-end secure WhatsApp, where either you are in the role of a participant in the conversation, or else you are in the role of a non-participant and are faced with encrypted ciphertext. Of course WhatsApp can and will be adopting both roles, but those roles are technically distinct, and when acting as a participant their “participant role” is visible to all other participants. Access to conversation plaintext will require continuous and ongoing effort by WhatsApp as an equal participant, rather just a simple database query.

What if a Messenger doesn’t satisfy the definition?

Then it does not deliver End-to-End Secure Messaging.

Challenge

Please find any holes in this definition.

I think it’s pretty good, but I want to make it bombproof.
[END]

[1] URL: https://alecmuffett.com/article/14275
[2] URL: https://creativecommons.org/licenses/by-sa/3.0/

DropSafe Blog via Magical.Fish Gopher News Feeds:
gopher://magical.fish/1/feeds/news/alecmuffett/

You are viewing proxied material from magical.fish. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.