From sgcWebSockets 2026.1.0 E2EE (End-To-End Encryption) is supported (only for eSeGeCe All-Access subscribers).
End-to-End Encryption (E2EE) ensures that only the communicating peers can read the content of exchanged messages. Even the server that routes the messages cannot decrypt them. This article explains how E2EE works between two peers using public-key cryptography to securely exchange messages.
E2EE Explained
Core Principles of E2EE
In a two-peer E2EE system:
- Each peer owns a private key that never leaves their device.
- Each peer publishes a public key that others can see.
- Messages are encrypted on the sender's device and decrypted only on the recipient's device.
- The server acts only as a message relay, not as a trusted party.
Each peer (for example, Alice and Bob) has:
- Private Key
A secret value stored locally. It must never be shared. - Public Key
A value derived from the private key. It can be shared freely.
Public and private keys are mathematically linked, but knowing the public key does not reveal the private key.
Before encrypted communication can occur, Alice and Bob must know each other's public keys.
Typical approaches:
- The server stores public keys and delivers them on request.
- Public keys are exchanged during account creation or first contact.
This exchange does not compromise security, because public keys are not secret.
To encrypt messages efficiently, Alice and Bob first derive a shared secret using Elliptic Curve Diffie–Hellman (ECDH).
How ECDH Works Conceptually- Alice computes a shared secret using:
- Her private key
- Bob's public key
- Bob computes a shared secret using:
- His private key
- Alice's public key
Because of the mathematical properties of elliptic curves, both computations produce the same secret value, even though neither side ever transmits that secret.
At no point is the shared secret sent over the network.
The raw ECDH shared secret is not used directly for encryption. Instead, it is processed through a Key Derivation Function (KDF), typically a cryptographic hash such as SHA-256.
Purpose of key derivation:
- Produce a key of the correct length (e.g., 32 bytes for AES-256)
- Remove structural bias from the raw ECDH output
- Improve cryptographic robustness
The result is a symmetric encryption key known only to Alice and Bob.
When Alice wants to send a message to Bob:
- Alice converts the message into bytes.
- Alice encrypts the message using a symmetric cipher (commonly AES-GCM) with:
- The derived symmetric key
- A random initialization vector (IV)
- Alice sends the encrypted message and IV to Bob via the server.
AES-GCM is commonly used because it provides:
- Confidentiality (encryption)
- Integrity (tamper detection)
- Authentication (detects forged messages)
When Bob receives the encrypted message:
- Bob independently derives the same symmetric key using ECDH and the same KDF.
- Bob decrypts the message using the symmetric key and IV.
- If authentication succeeds, Bob obtains the original plaintext.
If the message has been altered or the wrong key is used, decryption fails.
In this architecture, the server:
- Delivers public keys
- Routes encrypted messages
- Manages user presence or metadata
The server cannot:
- Derive shared secrets
- Decrypt messages
- Forge valid encrypted messages
This is the defining property of End-to-End Encryption.
Summary
End-to-End Encryption between two peers works by combining:
- Public-key cryptography (for key agreement)
- Symmetric cryptography (for efficient message encryption)
- Key derivation functions (for security and correctness)
The result is a system where:
- Only peers can read messages
- The server is reduced to a transport role
- Privacy is preserved by design, not by policy
This model is the cryptographic backbone of modern secure messaging systems.