Talk:End-to-end encryption

This article is or was the subject of a Wiki Education Foundation-supported course assignment. Further details are available on the course page. Student editor(s): Dorisdd. Peer reviewers: Dorisdd.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 20:42, 17 January 2022 (UTC) [reply ]

This article is literally mostly about Tetra. Is Tetra notable enough to get its own article so that this one can focus on its title and just reference Tetra as an example? Chris Arnesen 14:26, 25 March 2014 (UTC) [reply ]

I removed the "Example: Tetra" section because it gave undue weight to one particular example, and it was written like a personal essay. --Dodi 8238 (talk) 13:28, 17 November 2015 (UTC) [reply ]

When non-certified/uncertified (is there a difference?) E2EE is used, there is potential for Man-in-the-middle attacks, especially between parties that have not previously exchanged public keys in a more secure manner. Because the article presently does not describe this potential, a reader might wrongly conclude that E2EE is by itself a complete solution to privacy and security, which would be a very dangerous misconception. The article should at least briefly describe the MITM problem, as well as means for mitigation (e.g. web of trust). While I'm very familiar with the problem, I don't have the expertise to adequately describe the possible means of mitigation, and in particular can't explain how (or even whether) those methods are used by the cited examples of E2EE protocols, software and services (e.g., ZRTP, TETRA). --Brouhaha (talk) 18:49, 14 March 2015 (UTC) [reply ]

I removed a mention according to which Lavabit and Hushmail were not E2EE, which was not supported by the source (I put it back again later). I think to have read somewhere that Lavabit was E2EE before it closed, i.e. knowledge of the server's private key would not allow one to decrypt stored emails; the possible attack medium was by impersonating the server in the key exchange between the sender and the recipient of email, so that one could recover the client's key and read subsequent emails (and possibly the previous ones as well). Said otherwise, the server could be made insecure by changing the protocol, but the mail itself was secure until then.

However, by hunting around the web, I did not find it again. Does someone have a good source for that? The Wired one is the typical example of a layman journalist writing on a technical subject...

Tigraan ^{Click here to contact me} 15:14, 19 May 2016 (UTC) [reply ]

I note that the key exchange section is pretty odd.

pre-shared secret (PGP)

Pre-shared secrets / keys are typically used in symmetric systems and PGP (which can use symmetric keys) is best known as an asymmetric system where each party only needs the other party's public key, not a shared secret.

or a one-time secret derived from such a pre-shared secret (DUKPT)

The parenthetical link appears to be a method, not an example system like the others

They can also negotiate a secret key on the spot using Diffie-Hellman key exchange (OTR)

This seems fine

But perhaps a better way to look at this would be the Unger et al paper, SoK: Secure Messaging, section IV, Trust Establishment, which helpfully differentiates between authenticated and unauthenticated key exchange (which this current section fails to do). — Preceding unsigned comment added by SyntaxPolice (talk • contribs) 23:28, 1 June 2016 (UTC) [reply ]

Key Exchange:

In an E2EE system, encryption keys must only be known to the communicating parties. To achieve this goal, E2EE systems can encrypt data using a pre-arranged string of symbols, called a pre-shared secret (PGP), or a one-time secret derived from such a pre-shared secret (DUKPT). They can also negotiate a secret key on the spot using Diffie-Hellman key exchange (OTR).

→ PGP is widely considered as a hybrid cryptographic protocol, that uses both symmetric (SYM) and asymmetric operations (ASYM) for key-exchange (ASYM), message encryption/decryption (SYM+ASYM) and digital signing (SYM+ASYM). However, a pre-shared secret mechanism portrays a symmetric cryptographic operation that encapsulates a single key for both encryption and decryption, and therefore does not correspond to PGP at all.

→ Ephemeral key is another widely used mechanism to gain forward secrecy and currently being used in several E2EE applications (for e.g. Signal (software)).

Modern usage

Examples of end-to-end encryption include PGP, and ProtonMail, and S/MIME for email; OTR, iMessage, Signal, or Telegram and more recently WhatsApp for instant messaging; SpiderOak for backup and its Collaboration_tool Semaphor; ZRTP or FaceTime for telephony; and TETRA for radio.

→ Protonmail is a webmail and performs key-management on server-side. A better example for PGP is GnuPG

Challenges

→ This section should include following two parts, which currently are being considered as one of the biggest challenges in any given E2EE system.

1. Key Management
   

1. Key Distribution
   

M Salman Nadeem (talk) 12:32, 15 September 2016 (UTC) [reply ]

Instead of talking about E2EE it talks about 'sever end to end encryption' without discriminating clearly. E2EE is different, this makes it confusing. 217.149.160.172 (talk) 21:08, 8 December 2022 (UTC) [reply ]

I tried to make it a little clearer in my recent edits. ShreyasMinocha (talk) 23:22, 27 November 2024 (UTC) [reply ]

OF(end) — Preceding unsigned comment added by 37.238.213.11 (talk) 22:02, 19 December 2023 (UTC) [reply ]

This article needs to be updated to include a lot more info from the last 5-ish years.

• Present-day E2EE apps (messaging, but also video conferencing, file sharing etc)
• Motivations (restructuring and expansion of the "E2EE and privacy" section)
  • Recommended by digital freedom and human rights orgs
  • Use by journalists and informants, use in protests and by other at-risk populations
• Discussion of metadata privacy ('We Kill People Based on Metadata' circa 2014; see WA's fail])
• Backup encryption (WA is a case study again)
• Separate section(s) about LEA/Gov responses across the world e.g.
  • UK/US/AU/etc LEA/agency/govt responses to E2EE (Cryptowars)
    • Operation Trojan Shield
    • FBI changing course and recommending E2EE now
  • Legislation
    • Attempts at legislating against E2EE or requiring platforms to implement extraordinary access abilities
    • Quotes from lawmakers/agency heads
  • Service bans, blocks and censorship
    • Signal bans
    • ProtonMail blocks in India
• 2025 "Signalgate"
• Relationship with CSAM scanning efforts by Apple and others
  • In response to pressure from child safety groups
  • Related controversy, technical (in)feasibility — Preceding unsigned comment added by ShreyasMinocha (talk • contribs) 08:33, 13 July 2025 (UTC) [reply ]
• Some technical details, confined to their own section?
  • moderation under E2EE (technical e.g. message franking, traceback and also practical Trust and safety stuff)
  • deniability properties and legal status/precedent — Preceding unsigned comment added by ShreyasMinocha (talk • contribs) 08:34, 13 July 2025 (UTC) [reply ]
• The role of post-quantum cryptography (see also: Harvest now, decrypt later)
• Twitter (X) encrypted DMs history

I'm working on it, but any help is welcome. ShreyasMinocha (talk) 12:03, 4 July 2025 (UTC) [reply ]