{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"cs/end-to-end-encryption","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/cs/end-to-end-encryption/","da":"https://cmaintz.github.io/tech-atlas/da/terms/cs/end-to-end-encryption/"},"term":{"en":"End-to-end encryption","da":"End-to-end-kryptering"},"aka":{"en":["E2EE"],"da":["E2EE"]},"domain":["cs","security"],"cluster":"cryptography","layer":"application","status":"current","era":1991,"summary":{"en":"Scrambling a message on the sender's device so that only the receiver's device can read it, not even the service carrying it.","da":"At kryptere en besked på afsenderens enhed, så kun modtagerens enhed kan læse den - heller ikke tjenesten, der bringer den frem."},"body":{"formal":{"en":"A design in which data is encrypted on the sending device with keys held only by the people talking, so every server in between, including the provider's own, passes along data it has no key to read.","da":"Et design, hvor data krypteres på den afsendende enhed med nøgler, som kun de samtalende parter har, så alle servere undervejs, også udbyderens egne, sender data videre, som de ikke har nøgle til at læse."},"plain":{"en":"Like posting a locked box that only your friend has the key to - the postal service carries it all the way but can never open it.","da":"Som at sende en aflåst kasse, som kun din ven har nøglen til - posten bringer den hele vejen, men kan aldrig åbne den."},"inPractice":{"en":"A ministry lets staff use a chat app with end-to-end encryption on their work phones. IT can manage the phones, but a request to the app's provider for the chats would return nothing readable.","da":"Et ministerium lader medarbejderne bruge en chatapp med end-to-end-kryptering på arbejdstelefonerne. IT kan administrere telefonerne, men beder man appens udbyder om samtalerne, får man intet læsbart."},"whyItMatters":{"en":"Without it, every message can be read at the provider, so one break-in or one curious member of staff exposes everyone; the trade-off is that lost keys mean lost messages.","da":"Uden den kan alle beskeder læses hos udbyderen, så ét indbrud eller én nysgerrig medarbejder afslører alle; bagsiden er, at mistede nøgler betyder mistede beskeder."}},"deepDive":{"en":"The defining property is where the keys live: only on the endpoints, never with the operator of the relay. That makes E2EE a threat-model statement rather than an algorithm. It protects content against the server, its administrators, its cloud provider and anyone who compels or breaches them; it does not protect against a compromised endpoint, a malicious client update, or screenshots, and in most deployments it does not hide metadata such as who talks to whom, when, from which IP address and how often.\n\nThe dominant design for messaging is the Signal Protocol. Each device publishes an identity key and signed prekeys to the server; a sender runs an asynchronous key agreement (originally X3DH, replaced in 2023 by PQXDH, which adds a post-quantum KEM so that recorded traffic cannot later be decrypted with a quantum computer) and then the Double Ratchet. The ratchet derives a new message key for every message through a symmetric KDF chain and mixes in fresh Diffie-Hellman outputs whenever the direction of conversation changes. This gives forward secrecy (stealing today's keys does not reveal yesterday's messages) and post-compromise security (the conversation heals once new DH values are exchanged). WhatsApp and Google Messages' RCS chats use the Signal Protocol, Apple's iMessage moved to its PQ3 protocol in 2024, and Messaging Layer Security (RFC 9420, July 2023) standardises efficient group key agreement with a ratchet tree so that membership changes cost O(log n) instead of O(n).\n\nThe weakest point is key authentication. The server distributes public keys, so a malicious or coerced server could hand out its own key and sit in the middle. The countermeasures are out-of-band verification of safety numbers or QR codes and, increasingly, key transparency logs that make such substitutions publicly detectable. Multi-device support multiplies the problem: every linked device, web client and backup is another endpoint. Cloud backups are a classic gap; WhatsApp added optional end-to-end encrypted backups in 2021, and Apple's Advanced Data Protection extends E2EE to most iCloud categories but was withdrawn for new users in the UK in February 2025 after a government demand.\n\nE2EE differs from TLS, which is hop-by-hop and terminates at the provider, and from encryption at rest, where the provider holds the keys. In e-mail, OpenPGP (RFC 9580) and S/MIME provide E2EE for the message body only, leaving headers and subject in the clear. For organisations the trade-offs are concrete: E2EE conflicts with server-side malware scanning, legal hold, archiving obligations and DLP, and lost keys mean lost data. Proposals for client-side scanning to detect illegal content, debated in the EU for several years, would move inspection onto the endpoint and are widely criticised by cryptographers for undermining exactly the guarantee E2EE is meant to give.","da":"Den definerende egenskab er, hvor nøglerne befinder sig: kun hos endepunkterne, aldrig hos den, der driver mellemleddet. Det gør E2EE til et udsagn om trusselsmodellen snarere end en algoritme. Indholdet beskyttes mod serveren, dens administratorer, dens cloududbyder og enhver, der tvinger eller bryder ind hos dem; det beskytter ikke mod et kompromitteret endepunkt, en ondsindet klientopdatering eller skærmbilleder, og i de fleste løsninger skjules metadata ikke, fx hvem der taler med hvem, hvornår, fra hvilken IP-adresse og hvor ofte.\n\nDet dominerende design til beskedtjenester er Signal-protokollen. Hver enhed lægger en identitetsnøgle og signerede prekeys på serveren; afsenderen gennemfører en asynkron nøgleudveksling (oprindeligt X3DH, i 2023 afløst af PQXDH, som tilføjer en post-kvante-KEM, så optaget trafik ikke senere kan dekrypteres med en kvantecomputer) og derefter Double Ratchet. Ratchetten afleder en ny beskednøgle for hver besked via en symmetrisk KDF-kæde og blander friske Diffie-Hellman-værdier ind, hver gang samtalens retning skifter. Det giver forward secrecy (dagens stjålne nøgler afslører ikke gårsdagens beskeder) og post-compromise security (samtalen heler, når der er udvekslet nye DH-værdier). WhatsApp og RCS-chats i Google Beskeder bruger Signal-protokollen, Apples iMessage gik over til PQ3-protokollen i 2024, og Messaging Layer Security (RFC 9420, juli 2023) standardiserer effektiv gruppenøgleudveksling med et ratchet-træ, så ændringer i medlemskab koster O(log n) i stedet for O(n).\n\nDet svageste punkt er autentificering af nøgler. Serveren distribuerer de offentlige nøgler, så en ondsindet eller tvunget server kunne udlevere sin egen nøgle og placere sig i midten. Modtrækkene er verifikation af sikkerhedsnumre eller QR-koder ad anden vej og i stigende grad key transparency-logs, der gør den slags udskiftninger offentligt synlige. Understøttelse af flere enheder forstørrer problemet: hver tilknyttet enhed, webklient og backup er endnu et endepunkt. Cloud-backup er et klassisk hul; WhatsApp indførte valgfri end-to-end-krypterede backups i 2021, og Apples Advanced Data Protection udvider E2EE til de fleste iCloud-kategorier, men blev i februar 2025 trukket tilbage for nye brugere i Storbritannien efter et krav fra regeringen.\n\nE2EE adskiller sig fra TLS, der beskytter strækning for strækning og ender hos udbyderen, og fra kryptering af lagrede data, hvor udbyderen har nøglerne. I e-mail giver OpenPGP (RFC 9580) og S/MIME kun E2EE for selve beskedteksten, mens headere og emnelinje står i klartekst. For organisationer er afvejningerne konkrete: E2EE kolliderer med malwarescanning på serveren, litigation hold, arkiveringspligt og DLP, og mistede nøgler betyder mistede data. Forslag om client-side scanning for at finde ulovligt indhold, som har været debatteret i EU i flere år, vil flytte inspektionen ud på endepunktet og kritiseres bredt af kryptografer for at undergrave netop den garanti, E2EE skal give."},"edges":[{"type":"requires","to":"cs/public-key-cryptography","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/encryption","confidence":"high","strength":"normal"},{"type":"implements","to":"security/confidentiality","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"cs/tls","why":{"en":"TLS protects data only on each hop and the server reads it in the middle; end-to-end encryption keeps it closed all the way from sender to receiver.","da":"TLS beskytter kun data på hver strækning, og serveren læser dem undervejs; end-to-end-kryptering holder dem lukkede hele vejen fra afsender til modtager."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/data-breach","why":{"en":"A break-in at the provider's servers finds only scrambled messages, because the keys live on the users' devices.","da":"Et indbrud på udbyderens servere finder kun krypterede beskeder, fordi nøglerne ligger på brugernes enheder."},"confidence":"medium","strength":"normal"}],"depth":2,"sources":[{"title":"Signal Protocol documentation","url":"https://signal.org/docs/","tier":"official-doc","publisher":"Signal"},{"title":"End-to-end encryption (Wikipedia)","url":"https://en.wikipedia.org/wiki/End-to-end_encryption","tier":"reference"}],"draft":true}