← Cuadernos Lacre

Konsept · 18. mai 2026

Ende-til-ende-kryptering, forklart på ekte

Hva tilbydere sier når de sier E2EE, og hva de ikke sier. En didaktisk forklaring av mekanismen og dens grenser, uten reklameinnpakning.

Hva kryptering egentlig betyr

Å kryptere en melding betyr å transformere den til noe som ser ut som støy for alle som ikke besitter en bestemt informasjon kalt en nøkkel. Operasjonen gjøres på enheten til den som sender, og med riktig nøkkel omgjøres den på enheten til den som mottar. Imellom reiser meldingen som en rekke bytes uten tilsynelatende mening. Dette er den enkle ideen. Resten av artikkelen tar for seg nyansene som gjør den, alt etter tilfelle, til en reell garanti eller en markedsføringsetikett.

Adjektivet ende-til-ende — på engelsk end-to-end, forkortet E2EE — legger til en presisjon. Krypteringen gjøres ikke for at en mellomliggende server skal kunne lese og levere den. Den gjøres for at kun de to endene — enheten til den som sender og enheten til den som mottar — skal besitte nøkkelen. Enhver server som meldingen passerer gjennom, ser støyen, ikke meldingen. Dette er den tekniske forskjellen fra kryptering i transitt, der innholdet reiser kryptert fra én server til den neste, men hver server den passerer dekrypterer den for å videresende den, og gjenoppretter midlertidig teksten i klartekst.

Paradokset om den delte hemmeligheten

Det er et åpenbart problem. For at to personer skal kunne kryptere og dekryptere meldinger seg imellom, trenger begge den samme nøkkelen. Men hvordan blir de enige om denne nøkkelen hvis alt de sender hverandre, per definisjon, går gjennom en kanal der noen kan lytte? Å avtale nøkkelen i den samme kanalen som de senere skal bruke den i, virker umulig: hvis angriperen hører den ved avtalen, vil vedkommende kunne dekryptere alt etterfølgende. I tiår løste klassisk kryptografi dette på den harde måten: nøklene ble levert personlig, før de ble tatt i bruk, i fysiske møter. Ambassadører bar kofferter med nøkler sydd inn i foret på frakkene sine.

I moderne e-post er ikke den løsningen skalerbar. Hvis vi måtte gå fysisk hjem til hver person vi hadde til hensikt å kommunisere kryptert med, ville vi aldri komme til å snakke med noen. Spørsmålet som ble stilt for femti år siden av det kryptografiske miljøet var dette: er det mulig for to personer som ikke kjenner hverandre og som bare deler en offentlig kanal, å avtale en hemmelighet i den samme offentlige kanalen, som ingen som lytter til kanalen kan vite om?

Elegansen i Diffie-Hellman

I 1976 demonstrerte to matematikere ved navn Whitfield Diffie og Martin Hellman noe tilsynelatende umulig: at to personer, som bare snakker gjennom en offentlig kanal — en kanal der hvem som helst kan høre alt de sier — kan bli enige om et hemmelig passord uten at noen lytter kan oppdage det. Det høres ut som magi. Det er det ikke: det er matematikk. Diffie-Hellman-nøkkelutveksling, som det har vært kjent som siden da, er grunnlaget for praktisk talt all kryptert kommunikasjon på internett, og et halvt århundre med intensiv bruk og global akademisk gransking bekrefter soliditeten. De som vil se den visuelle intuisjonen eller matematikken, kan lese videre. De som foretrekker å stole på at det fungerer, kan også fortsette uten å miste tråden i artikkelen.

For de som vil visualisere det, finnes det en kjent analogi med farger. Tenk deg at Alice og Bruno blir enige om en grunnfarge offentlig — la oss si gult — foran øynene på Eva, som lytter til dem. Hver velger en annen hemmelig farge privat og blander sin hemmelighet med den gule. Alice får en bestemt oransje; Bruno får en bestemt grønn. De utveksler resultatene foran øynene på Eva. Nå blander hver den mottatte fargen med sin egen hemmelighet, og begge når frem til den samme sluttfargen, fordi rekkefølgen på blandingene ikke betyr noe. Eva har sett det gule og de to mellomliggende blandingene, men ikke hemmelighetene; uten en av hemmelighetene kan hun ikke nå frem til sluttfargen. Den virkelige matematikken erstatter fargene med eksponentiering i modulære grupper eller elliptiske kurver, men ideen er den samme: den delte hemmeligheten bygges offentlig uten at noen i kanalen kan rekonstruere den.

Fra Diffie-Hellman til Signal-protokollen

Ende-til-ende-kryptering som brukes av dagens profesjonelle meldingsapper hviler, nesten uten unntak, på en elegant og herdet versjon av Diffie-Hellman-utvekslingen. Signal-protokollen, designet av Trevor Perrin og Moxie Marlinspike mellom 2013 og 2016, er referansen. Den kombinerer to nøkkelideer. Den første er nøkkelutveksling i elliptiske kurver (X25519), som produserer den opprinnelige delte hemmeligheten mellom to enheter. Den andre er den såkalte Double Ratchet — dobbelt tannhjul — som fornyer nøklene automatisk med hver melding, slik at kompromittering av enheten i dag ikke tillater dekryptering av tidligere meldinger, heller ikke fremtidige meldinger når tannhjulet er dreid.

I Zig tar X25519-utvekslingen som produserer den delte hemmeligheten mellom to enheter seks linjer, ved bruk av standardbiblioteket:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

Og hva nøyaktig er inne i std.crypto.dh.X25519? Ingen skjult magi. Det er to korte funksjoner som kan leses i sin helhet i Zigs eget standardbibliotek. Den første utleder den offentlige nøkkelen fra den private — utvekslingens «gᵃ»:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

I artikkelens språk: den private nøkkelen «multipliseres» — i elliptisk forstand, ikke i grunnleggende aritmetisk forstand — med basispunktet for Curve25519-kurven, og resultatet serialiseres til trettito bytes. Operasjonen clampedMul er den herdede versjonen av den skalare multiplikasjonen: den inkorporerer sikkerhetsmekanismene som det kryptografiske miljøet har lagt til gjennom årene for å motstå kjente familier av angrep. To linjer med funksjonskropp.

Den andre funksjonen kombinerer din private nøkkel med den offentlige nøkkelen som den andre parten sender deg. Det er utvekslingens «(gᵇ)ᵃ», som produserer den trettito bytes store delte hemmeligheten som ingen av dere noen gang overførte:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

To linjer til. Den mottatte offentlige nøkkelen tolkes som et punkt på kurven, og «multipliseres» med ens egen private nøkkel. På grunn av kurveoperasjonens kommutative egenskap — analog til kommutativiteten i eksponentmultiplikasjonen som vi så i det numeriske eksemplet — ender begge parter opp med det samme serialiserte punktet: nøyaktig den delte hemmeligheten som artikkelen snakker om.

Hva ende-til-ende-kryptering beskytter

Det E2EE beskytter godt, forutsatt en korrekt implementering, er innholdet i meldingen under transitt. En mellomliggende server som mottar og videresender de krypterte dataene vil se en rekke uforståelige bytes. En angriper med tilgang til kabelen, ruteren, wifi-aksesspunktet vil se det samme. En tjenesteleverandør som oppbevarer kopier av trafikken vil ikke kunne lese den i ettertid. En regjering som pålegger tjenesteoperatøren å utlevere innholdet vil motta de samme uforståelige bytene som serveren hadde i utgangspunktet.

Dette er, i praktiske termer, mye. Det er forskjellen mellom å skrive et brev inni en ugjennomsiktig konvolutt og å skrive det på et postkort. Begge kommer frem. Bare én bevarer innholdet overfor postmannen.

Hva ende-til-ende-kryptering ikke beskytter

Det er verdt å vite det like godt. E2EE beskytter ikke metadata: serveren vet fortsatt at bruker A sender data til bruker B, på hvilket tidspunkt, med hvilken frekvens og hvorfra, selv om den ikke vet hva som blir sagt. Disse metadataene, som vi allerede har argumentert for i Å kryptere er ikke å være privat, er ofte mer avslørende enn innholdet. Å vite at noen ringte et advokatfirma spesialisert på skilsmisser en fredag kl. 22.00 i tretti minutter forteller en historie som innholdet i samtalen aldri fortalte. Det er samme situasjon som å se en person gå inn og ut av en onkologisk klinikk flere ganger: man trenger ikke høre noe av det som blir sagt inne for å forestille seg hva som skjer. Ett enkelt isolert metadatakunne betyr kanskje ingenting; flere kryssrefererte tegner noe som er altfor likt sannheten. E2EE beskytter ikke endepunktene: hvis mottakerens enhet er kompromittert av et ondsinnet program, dekrypteres meldingen normalt for den mottakeren og det ondsinnede programmet leser den. E2EE beskytter ikke mot identiteten til samtalepartneren i seg selv: hvis Alice tror hun snakker med Bruno, men en angriper har skutt seg inn i starten (en man in the middle) og protokollen ikke inkluderer uavhengig verifisering, ender de to partene med å snakke med inntrengeren i troen på at de snakker med hverandre.

Det er en fjerde ting som er verdt å formulere uten tvetydighet. E2EE hindrer ikke en leverandør som hevder å tilby det fra å også lagre en kopi av den ukrypterte meldingen i sine egne systemer. Påstanden «mine meldinger er ende-til-ende-kryptert» og påstanden «leverandøren lagrer ikke mitt innhold» er ikke de samme. En app kan oppfylle den første mens den bryter den andre; vi har sett det i avisoverskrifter gjentatte ganger siden 2018. Brukeren har, med mindre klientens kode er verifiserbar, ingen teknisk måte å skille ett tilfelle fra det andre uten ekspertundersøkelse. Det mest kjente tilfellet i den brede offentligheten: WhatsApp krypterer meldinger ende-til-ende under transitt, men hvis brukeren aktiverer sikkerhetskopi i iCloud eller Google Drive uten ytterligere kryptering, lagres den kopien lesbart i en tredjeparts infrastruktur, og krypteringen brytes i brukerens egen ende.

Spørsmålet operatøren ikke ønsker å høre

En app som hevder å kryptere ende-til-ende kan teknisk sett gjøre én av tre ting med hensyn til nøklene:

  1. Nøklene bor kun på enhetene. De genereres og bor utelukkende på brukernes enheter; operatøren kjenner dem ikke og lagrer dem ikke. Dette er det optimale tilfellet.
  2. Operatøren kan få tilgang hvis de vil. Operatøren har brukernes nøkler (eller kan generere dem etter eget ønske) og lagrer dem i sine databaser. Hvis de vil eller blir tvunget til det, kan de lese innholdet. Dette er tilfellet for de fleste «skybaserte» tjenester.
  3. Operatøren kan ikke få tilgang ved design, men de kontrollerer tilgangen. Operatøren har ikke nøklene, men har kontroll over applikasjonen som genererer dem. Hvis de blir tvunget, kan de sende en ondsinnet oppdatering som fanger opp nøklene eller innholdet før kryptering. Dette er tilfellet for mange kommersielle E2EE-tjenester.

Det operative spørsmålet er derfor ikke om noe er kryptert, men hvem som har kontroll over enheten og programvaren som administrerer nøklene. I Solo2 befinner nøklene seg utelukkende i ditt Hvelv (IndexedDB kryptert med ditt passord), og programvaren er verifiserbar åpen kildekode.

For den profesjonelle leseren

Ende-til-ende-kryptering er et verktøy for digital suverenitet. Men som ethvert verktøy, avhenger effektiviteten av hånden som fører det og grunnen det står på.

  1. Hvor genereres de kryptografiske nøklene, og hvor befinner de seg fysisk? Hvis operatøren kan få tilgang til dem (selv midlertidig, selv under påskudd av gjenoppretting), er E2EE kun nominell.
  2. Finnes det uavhengig verifisering av samtalepartneren (sikkerhetsnumre, QR-koder, out-of-band sammenligning) som forhindrer et man-in-the-middle-angrep under etableringen av samtalen?
  3. Kan klientkoden revideres — er den åpen, publisert, reproduserbar — eller krever det at vi stoler på leverandørens ord om hva klienten faktisk gjør?
  4. Hvilke metadata genererer og lagrer tjenesten, og for hvor lenge? Selv om innholdet er ugjennomsiktig, kan metadata rekonstruere en god del av den sensitive informasjonen.

Disse fire spørsmålene ber ikke om avansert teknisk informasjon; de ber om informasjon som enhver ærlig operatør kan svare på i sin offentlige dokumentasjon. Kvaliteten og presisjonen av svaret sier like mye om produktet som selve svaret.


Ende-til-ende-kryptering, når det er gjort riktig, er en av de fineste konstruksjonene som moderne kryptografi har levert til daglig praksis. Den opprinnelige ideen — at to personer kan bli enige om en hemmelighet via en offentlig kanal — tilhører Whitfield Diffie og Martin Hellman, 1976; et halvt århundre senere lever vi fortsatt i konsekvensen av den. Men som med ethvert teknisk løfte, avhenger verdien av reell oppfyllelse, ikke av etiketten. Den ærlige fagpersonens spørsmål er ikke «er det kryptert?», men «hvem har nøklene?». Svarene har ulike konsekvenser. Det er verdt å kjenne dem.

Kilder og videre lesing

  • Diffie, W.; Hellman, M. — New Directions in Cryptography, IEEE Transactions on Information Theory, november 1976. Grunnleggende artikkel om offentlig nøkkel-kryptografi.
  • Perrin, T.; Marlinspike, M. — The Double Ratchet Algorithm, offentlig spesifikasjon fra Open Whisper Systems, revisjon 2016. Grunnlaget for Signal-protokollen og dens industrielle derivater.
  • RFC 7748 — Elliptic Curves for Security (IETF, januar 2016). Normativ spesifikasjon av X25519- og X448-kurvene som brukes i moderne nøkkelutvekslinger.
  • Ferguson, N.; Schneier, B.; Kohno, T. — Cryptography Engineering: Design Principles and Practical Applications (Wiley, 2010). Kapitler om nøkkelutveksling og autentiserte krypteringsprotokoller.
  • Forordning (EU) 2024/1183 om rammeverk for europeisk digital identitet (eIDAS 2) — etablerer rammeverk der uavhengig verifisering av samtalepartneren får institusjonell støtte, og der skillet mellom nominell og reell kryptering har ulike juridiske konsekvenser.

Siste lesninger