End-to-End Encryption (E2EE): Your Complete Guide

A communication creates two sets of cryptographic keys, one public and one private, for each user. This process is known as asymmetric cryptography because a user’s public and corresponding private keys are distinct but related:

• Public keys encrypt or lock the data through large numerical values created by an algorithm. Every user has their own public key, and it’s shared with every other user on the system, application, or network. Public keys are validated by being embedded in a certificate that is signed by a recognized certificate authority (CA).
• Private keys decrypt or unlock the data that was secured by their paired public key. Private keys are unique, belong only to the owner, and are not shared with other users.

For context, while asymmetric encryption relies on two different cryptographic keys at either endpoint, its inverse, symmetric decryption, only relies on one. For this reason, symmetric encryption is also known as single-key encryption.

With E2EE, encryption occurs at both endpoints at the device level, whether it’s a mobile device, point of sale device, or personal computer. You can think of the E2EE process as follows:

1. Key generation: When a user joins a system, they receive unique public and private cryptographic keys
2. Key exchange: Whenever two users need to share information, they exchange public keys
3. Encryption: The sender’s device encrypts the information using the recipient’s public key
4. Transmission: The encrypted information is transmitted over a network or communication channel to the recipient’s device
5. Decryption: The recipient’s device uses their own private key to decrypt the message back to its original readable format or plaintext

For example, let’s say John wants to send Jane payment information. The information that John sends is first encrypted using Jane’s public key. That data remains encrypted while in transit, even while it is stored on a server. 

In this state, it is unreadable (and, therefore, unusable) by any unauthorized third party, including John and Jane’s internet service providers (ISPs), their application service providers, and any other entities or services. Hackers are also unable to access the information. Even if they intercept the transmission or break into the server, they don’t have the unique private key needed to decrypt the data.

Once the data reaches Jane’s device, it is decrypted by her related private key, and Jane is able to access the information. If Jane needs to send a response to John, her message will be encrypted using John’s public key.

Here’s how E2EE compares to each:

Encryption in transit

Encryption in transit protects data only while it travels between a device and a server. The Transport Layer Security (TLS) protocol behind most secure websites is an example of this. Once the data arrives at the server, it is decrypted, so the provider, along with anyone who breaches that server, can read it there.

Encryption at rest

With encryption at rest, data is encrypted while stored on a server or disk, though the decryption keys usually sit with the provider on the same system. This guards stored information if the hardware is stolen, yet it offers no protection while data moves across a network, and one compromised server can expose everything on it.

Link encryption

Link encryption, which is common on telecom and satellite connections, protects data one hop at a time. Data is decrypted at each node along a route, so that the device can read the routing information, then be re-encrypted before it continues on in its journey.

Field-level encryption

Field-level encryption targets specific pieces of data, such as a card number, Social Security number, or password, instead of a whole message. Those fields are encrypted before they reach the server and stay encrypted in storage, logs, and backups, so even an administrator with database access can’t read them without the keys.

Point-to-point encryption (P2PE)

Point-to-point encryption (P2PE) is the closest thing to E2EE, since it also encrypts and decrypts only at endpoints. However, P2PE solutions come with an added layer of protection because they must pass an assessment by a P2PE Qualified Security Assessor to be listed by the PCI Security Standards Council (PCI SSC). PCI SSC validation confirms that all the devices, applications, and processes used to encrypt and decrypt payments data are secure.

• A hacker may execute a man-in-the-middle (MITM) attack where they attempt to impersonate a message recipient. They’ll either impersonate their target during a public key exchange or substitute their public key for the intended recipient’s. This type of attack enables hackers to use their own private key to decrypt the message.
• A hacker could also attack either of the endpoint devices. Once they gain access to a device, they could steal a cryptographic key to later attempt a MITM attack. They could even just read the decrypted messages on the device from log files or as the user accesses them in real time.
• Some networks may have a backdoor, which is a secret means of access built into a system, enabling attackers to bypass regular encryption or authentication protections. While backdoors do have legitimate use cases, such as a developer creating one for easier access to an operating system or application, cybercriminals can also install them as malware.

Concrete examples of E2EE include:

• Email platforms and mobile messaging services use E2EE to ensure no one but the sender and recipient can read texts or listen to audio messages. Email can also use E2EE through standards such as Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME), which encrypt a message for a specific recipient and can sign it to prove who sent it.
• Some video conferencing tools offer E2EE for calls so content can’t be pulled from the provider’s servers or intercepted in transit.
• Password management systems often leverage E2EE to keep the company that stores the vault from reading it. The key stays on the user’s side, so any breach to the provider’s systems won’t expose login credentials or other sensitive information.

• Encrypted cloud storage and file-sharing services apply E2EE to documents before they leave the sender’s device, which keeps the provider from reading the file it hosts. This is especially valuable for legal, medical, and financial records that could cause serious harm if exposed.
• Electronic point-of-sale (POS) systems may use E2EE when transferring customers’ payment credentials.
• Merchants can use E2EE to protect card numbers, magnetic stripe data, and security codes and comply with the Payment Card Industry Data Security Standard (PCI DSS) — though they need to work closely with their acquirer or payment brand to ensure full compliance.