Talk:End-to-end encryption

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Wiki Education Foundation-supported course assignment[edit]

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]

Inordinate amount of page space devoted to Tetra[edit]

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]

Article should describe potential vulnerability to MITM attacks, and means for mitigation[edit]

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]

Unsure about that info (Lavabit not E2EE?)[edit]

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

TigraanClick here to contact me 15:14, 19 May 2016 (UTC)[reply]

Parenthetical examples in 'key exchange'[edit]

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 (talkcontribs) 23:28, 1 June 2016 (UTC)[reply]

Need more clarity[edit]

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]

Section 'E2EE and privacy' is poorly written while confusing[edit]

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]

OF(end)[edit]

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