What End-to-End encryption is and what it means
End-to-End encryption (E2E) is a way of protecting information in which a message is encrypted directly on the sender's device and decrypted only on the recipient's device. The two "ends" are the devices of the two parties; along the entire path between them — including the provider, the internet link and the server — the data stays encrypted and unreadable.
The core idea is simple: the secret key — the only thing that can decrypt the message — never leaves the device. The server merely relays the "envelope" (the encrypted bytes), but it cannot open the text inside, because it does not hold the key.
How it differs from transport encryption
When many services say "we use encryption", they usually mean transport encryption (for example HTTPS or TLS). That matters, but it is not enough. The difference is easiest to picture like this:
- Transport encryption (in-transit): the message is protected while it travels from the device to the server, but at the server it is decrypted and may be stored or processed in the clear. The server — or whoever controls it — can read the conversation.
- End-to-End encryption: the message stays encrypted along the entire path from sender to recipient. The server acts only as a "blind courier" — it carries the data but cannot read it.
Good systems combine both layers: E2E protects the message content, while transport (TLS 1.3) hides the metadata and the connection from an outside observer.
Why only the sender and recipient can read it
This is not magic but the result of asymmetric cryptography. Each user has a key pair: a public key, which can be shared, and a private key, which stays only on the device.
- Using the recipient's public key, the sender derives a shared session key and encrypts the message.
- Only the recipient's private key can reconstruct that session key and decrypt the message.
- Because the private key never leaves the device, no one in the middle — including the server — can open the message.
This is exactly why the E2E model works on the principle of "the server does not have to be trusted" rather than "we made the server trustworthy": even if the server is breached, the data on it stays unreadable.
Key concepts: keys, forward secrecy, verification
Keys on the device
The heart of E2E is where the keys are stored. If the keys live on the server, it is no longer E2E. In a proper implementation the keys reside only on the user's device, in the operating system's secure storage.
Forward secrecy
Modern protocols rotate the key for every message or session. As a result, even if one key is compromised, earlier conversations cannot be decrypted.
Verifying the other party
E2E is only trustworthy when you are sure "who" you are talking to. That is why reliable systems let you compare key "fingerprints" and rule out a man-in-the-middle attack.
How HAMA handles this
HAMA is a single secure platform for organizations in Uzbekistan (business and government bodies). For messaging, HAMA uses the Signal protocol, which has become an industry standard:
- X3DH (Extended Triple Diffie-Hellman) — provides a secure initial key exchange even when the other party is offline.
- Double Ratchet — rotates the key for each message, delivering both forward and backward secrecy.
- AES-256-GCM — used to encrypt group messages.
- TLS 1.3 — as an additional layer of protection at the transport level.
- Keys in the OS secure store, and the local database is encrypted with SQLCipher — conversations stay protected even if a device is stolen.
In addition, the HAMA server is hosted in Uzbekistan or deployed on-premise within the organization's own infrastructure, and the data is stored inside the country. The platform is preparing for compliance with O'z DSt ISO/IEC 27001:2023 and the requirements of PP-167 (critical information infrastructure).