End-to-end encryption for your web app and Android app
With end-to-end encryption, content is encrypted on the device; the server stores it but does not receive the key. Sortia Labs builds this into web apps and Android apps, as in our own product Postkey, with key management, sign-in and recovery that suit your users.
- End-to-end encryption
- Encryption in the browser
- AES-256-GCM
- OPAQUE
- Post-quantum cryptography
What end-to-end encryption involves
Encryption on the device
Texts, files and even file names are encrypted in the browser or the app before they are uploaded, with established methods such as AES-256-GCM. In plain text the server receives only what it needs to do its job.
Keys and recovery
The real work is not the algorithm but the handling of keys: new devices, forgotten passwords, staff who leave the company. We plan from the start how people get back to their data.
Sign-in that protects the password
Methods such as OPAQUE do not send the password itself to the server, and the device derives the key locally. A second factor by authenticator app or a security key such as a YubiKey adds protection to the account.
Sharing without a key on the server
Shared content stays encrypted too: the key sits in the part of the link after the #, which the browser does not send to the server. An expiry time, a password and an open limit can be added.
Saying openly what stays visible
The server usually still sees e-mail addresses, file sizes and times. We decide which metadata is needed and describe it so that the privacy policy and the technology match.
How we build encryption into your application
- 1
Threat model
Who should the data be protected from: attackers on the server, the operator, curious administrators? The answer decides what is encrypted and what the server may see.
- 2
Key concept
We define how keys are created, where they are kept and how they are shared and recovered. We rely on established, openly reviewed methods rather than home-made cryptography.
- 3
Build and verify
Tests with known test vectors, code review and a look at the actual network traffic check that only encrypted content leaves the device.
- 4
Operation and upkeep
Libraries get updates, methods are replaced when needed, and the documentation for privacy and audits stays current. Encryption is not a one-off task.
Software we build and run ourselves.
Questions about End-to-end encryption
How is end-to-end encryption different from TLS?
TLS protects data on its way to the server; once there, the operator can read it. With end-to-end encryption only the users' devices hold the keys, and the server stores encrypted data. The two belong together: TLS for the transport, end-to-end encryption for the content.
Do search and previews still work?
Yes, but on the device instead of on the server. The application decrypts the data locally and searches or displays it there; this is how Postkey opens PDF, Word and Excel files right in the browser. Full-text search across large archives needs its own design, which we plan early.
What happens if a user forgets the password?
This has to be decided before the first line of code. Common options are a printable recovery key, a second device or a key held by an authorised person in the company. In Postkey a Recovery key opens the data without the password; if both are lost, the data can no longer be opened.
Do we need post-quantum cryptography today?
For data that must stay confidential for many years, it is worth starting now: traffic recorded today could be decrypted by a future quantum computer. A hybrid key exchange combines a new method such as ML-KEM, standardised by the US agency NIST in 2024, with a proven classical one, so both would have to be broken.
Read on.
Planning an application with confidential data?
Tell us which data needs protecting and who may see it. We show you what a suitable key concept could look like and what it means for usability and recovery.