Kryptering på klientsiden ved deling af hemmeligheder

Kryptering på klientsiden beskytter en gemt hemmelighed mod operatøren og mod alle, der får fat i databasen, og intet andet: Ondsindet JavaScript, en browserudvidelse eller et lækket link sætter den ud af spil, fordi nøglen følger med linket. Den er ingen mirakelkur, og den ene garanti, den giver, betaler man for andre steder.

Denne guide forklarer, hvad kryptering i browseren garanterer, hvor den stille og roligt svigter, hvordan den står i forhold til modellen på serversiden, og hvordan LinkPilot har kombineret de to siden 29. september 2026, da generatoren til hemmelige engangslinks gik over til at kryptere i browseren.

Omskrevet 19. oktober 2026. Den oprindelige version af artiklen beskrev LinkPilots daværende model på serversiden; en note tilføjet den 29. september 2026 registrerede skiftet. Denne version beskriver den nuværende model hele vejen igennem. Ræsonnementet om, hvad hver model beskytter og ikke beskytter, er uændret.

Hvad beskytter kryptering på klientsiden egentlig?

Den gemte hemmelighed, mod operatøren og mod alle, der får fat i databasen. I et værktøj til hemmeligheder med kryptering på klientsiden (også kaldet end-to-end-krypteret eller E2EE) foregår det sådan:

1. Browseren genererer en symmetrisk nøgle, typisk en 256-bit AES-GCM-nøgle via Web Crypto API (crypto.subtle.generateKey).
2. Indholdet krypteres i browseren med den nøgle.
3. Kun chifferteksten sendes til serveren, som gemmer den under en tilfældig identifikator.
4. Nøglen sættes på delingslinket som et fragment (#…). Ifølge RFC 3986, afsnit 3.5 sender browsere aldrig fragmentet med i HTTP-forespørgsler, så nøglen når aldrig frem til serveren.
5. Modtagerens browser læser fragmentet, henter chifferteksten og dekrypterer lokalt.

Serveren ser kun chiffertekst. En operatør, der læser sin egen database, en sikkerhedskopi af databasen, der lækker, en retskendelse om udlevering af gemte data: Ingen af dem giver adgang til hemmeligheden, forudsat at alle andre led i kæden holder.

Sådan er et E2EE-link bygget op

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

Alt før # sendes med i forespørgslen og kan dukke op i server- og proxylogge. Fragmentet behandles kun af modtagerens browser. Det ene tegn står for hele sikkerheden. Det er elegant, og det er også roden til de fleste af fejlscenarierne nedenfor.

Hvad beskytter kryptering på klientsiden ikke mod?

Ondsindet eller kompromitteret JavaScript, browserudvidelser og et lækket link, fordi nøglen ligger i linket.

• Den beskytter ikke mod ondsindet JavaScript. Krypteringskoden kører i browseren, og browseren har fået koden fra serveren. Hvis serveren leverer ændret kode, fordi operatøren er blevet ondsindet, er blevet tvunget til det eller er blevet hacket, kan hemmeligheden læses før krypteringen eller efter dekrypteringen. Det er den grundlæggende grænse for E2EE i browseren.
• Den beskytter ikke mod browserudvidelser. En udvidelse med adgang til siden ser klarteksten efter dekrypteringen og kan læse fragmentet direkte.
• Den gør ikke et lækket link harmløst. Nøglen er en del af linket. Hvis modtageren indsætter hele linket i en chat, videresender e-mailen eller har synkronisering af browserhistorik slået til, følger nøglen med. Et E2EE-link med en lækket URL er en hemmelighed, der kan læses fuldt ud. Det eneste forsvar er en adgangssætning sendt ad en anden kanal, og derfor blander LinkPilot adgangssætningen ind i nøglen i stedet for at kontrollere den separat.
• Den reviderer, scanner og forhåndsviser ikke indhold. Da serveren ikke kan læse indholdet, kan den ikke filtrere det, scanne det for malware eller køre DLP (forebyggelse af datalæk) på det. Kontrollerne må i stedet virke på chifferteksten og på adgangshændelser.

Problemet med levering af koden, forklaret

Det, der er værd at dvæle ved: E2EE i browseren betyder, at du stoler på, at den server, du angiveligt ikke stoler på, leverer ærligt JavaScript, hver gang siden indlæses. En app installeres én gang, er signeret og har et versionsnummer; en webside hentes igen ved hvert besøg. Subresource Integrity og offentliggjort kildekode gør afstanden mindre uden at lukke den.

Ærligt læst betyder ”Vi kan ikke læse dine hemmeligheder” derfor ”Vi kan ikke læse dine hemmeligheder passivt”. At gøre en passiv mulighed til et aktivt angreb, der leverer ændret kode, kræver reelt mere af angriberen (aktive angreb er mere risikable, målrettede og kan potentielt opdages), men det er ikke det samme som ”umuligt”. Det gælder lige så meget LinkPilots påstand som alle andres.

Alternativet på serversiden

Det andet almindelige design, som LinkPilot brugte indtil september 2026, krypterer data i hvile på serveren og beskytter visningen med en hashet adgangssætning:

• TLS under overførslen; indholdet gemmes i en dedikeret tabel i en database med kryptering i hvile på diskniveau.
• Adgangssætninger hashes i browseren før overførslen og sammenlignes som hash; den rå adgangssætning når aldrig databasen.
• Destruktiv sletning: Ved første visning, udløb eller tilbagekaldelse overskrives det gemte indhold, og senere forsøg får HTTP 410.
• Forsøg med adgangssætningen begrænses og logges.

I denne model kan serveren læse en aktiv hemmelighed. Det er det, der gør forhåndsvisning, scanning og indholdsafhængige funktioner på serversiden mulige, og det er præcis den egenskab, E2EE fjerner. Open source-værktøjer som OneTimeSecret bruger den stadig; Er OneTimeSecret sikkert? ser på konsekvenserne.

Hvad LinkPilot gør nu

Siden 29. september 2026 har LinkPilot brugt kryptering på klientsiden og beholdt de kontroller på serversiden, der ikke kræver indholdet. Fra siden om sikkerhedsarkitekturen:

• Kryptering i browseren. Indholdet krypteres med AES-GCM-256 med en 256-bit nøgle, der genereres i afsenderens browser. Serveren gemmer chifferteksten og intet andet; nøglen følger med i den del af delingslinket, der står efter #.
• Adgangssætningen som en del af nøglen (Pro). En adgangssætning strækkes med PBKDF2-SHA256 (210.000 iterationer) og kombineres med linkets nøgle via HKDF-SHA256, så hverken linket alene eller adgangssætningen alene kan dekryptere hemmeligheden. Forsøg begrænses til 5 pr. IP-adresse pr. minut pr. hemmelighed, både af en begrænser i hukommelsen og af et glidende vindue i databasen.
• Slet efter læsning på chifferteksten. Visningen registreres i ét udeleligt trin gennem en databasefunktion, så samtidige forsøg på at vise hemmeligheden ikke kan lække den to gange; den gemte chiffertekst overskrives med [REDACTED], og senere forsøg returnerer HTTP 410.
• Tilbagekaldelse. En hemmelighed kan til enhver tid tilbagekaldes fra dashboardet; tilbagekaldte hemmeligheder vises ikke og returnerer 410.
• Visning, der tåler forhåndsvisninger. Forhåndsvisningsbots og e-mailscannere sender GET-forespørgsler, som kun returnerer metadata (status, og om der kræves en adgangssætning). En visning registreres kun, når nogen udtrykkeligt viser indholdet i en browser.
• Revisionslog (Pro). Oprettet, vist, forkert adgangssætning, slettet, udløbet og tilbagekaldt, hver med et tidsstempel, det land og den by, edge-udbyderen angiver, browserens identifikation og en hash af adressen med et dagligt salt. Revisionsloggen registrerer adgang, aldrig indhold.
• Filer. Vedhæftede filer krypteres også i browseren, med en nøgle, der er afledt af linkets nøgle. En fils navn, størrelse og type er fortsat synlige for LinkPilot som metadata.

Tre begrænsninger, sagt ligeud. Hemmeligheder, der blev oprettet før 29. september 2026, var gemt i klartekst, indtil de udløb; de blev aldrig omskrevet. Filers metadata er synlige, selv om filernes indhold ikke er. Og alt i afsnittet om, hvad den ikke beskytter mod, gælder stadig: Ondsindet JavaScript, browserudvidelser og et lækket link løses hverken af denne model eller af nogen anden model i browseren.

Afvejningerne samlet

Ingen model er ”mere sikker” i abstrakt forstand. De forsvarer mod forskellige trusler til forskellige omkostninger, og når man kombinerer dem, bliver listen over det, man opgiver, kortere, men den forsvinder ikke.

Model og trussel: tre scenarier

1. Du sender en adgangskode til en database til en ekstern konsulent. Truslen er, at hemmeligheden bliver liggende i e-mail eller chat, eller at den bliver videresendt ved en fejl. Alle modellerne klarer det med et kort udløb og Slet efter læsning; det afgørende er brugervenligheden og registreringen. Kryptering i browseren med en adgangssætning, der sendes ad en anden kanal, og en revisionslog, der viser, hvornår linket blev åbnet, er det pragmatiske valg.

2. En journalist modtager materiale fra en kilde. Trusselsmodellen omfatter, at platformens operatør tvinges til at udlevere data. Her er operatøren en del af truslen, så E2EE er et minimum, og specialbyggede værktøjer som SecureDrop, hvor hele systemet er designet omkring netop den trussel, er det rigtige valg. Et webværktøj, der kan tvinges til at levere ændret JavaScript, er ikke nok alene.

3. Et udviklingsteam, der rutinemæssigt overdrager loginoplysninger. Truslen er spredning: glemte links og ingen registrering af, hvem der så hvad. Det, der tæller, er revisionsloggen, tilbagekaldelse, roller i arbejdsområdet og en politik for udløb. Det krævede tidligere en server, der kunne læse indholdet. Det gør det ikke længere, fordi funktionerne virker på chiffertekst og adgangshændelser. Sikker deling af adgangskoder for teams dækker politikken i dette scenarie.

Sådan vælger du

Vælg kryptering på klientsiden, når:

• Du ikke stoler på operatøren, heller ikke dig selv, når du kører på en cloudinfrastruktur, du ikke kan efterprøve fuldt ud.
• Regler eller kontrakter kræver, at udbyderen teknisk set ikke kan læse indholdet.
• Du sender adgangssætningen ad en anden kanal og holder udløbet kort, for ellers er et lækket link hele hemmeligheden.

Vælg kryptering på serversiden, når:

• Serveren skal kunne undersøge indholdet: malwarescanning, DLP, filtrering af indhold.
• Du selv hoster et værktøj med ét formål, og operatøren er dig.

Se efter begge dele, når:

• Du vil have operatøren ud af tillidskæden og stadig har brug for en revisionslog, tilbagekaldelse, roller i teamet og en visning, som en forhåndsvisning af linket ikke kan udløse. Spørg udbyderen, hvilke kontroller der virker på chiffertekst, og hvilke der i det stille kræver klartekst.

Er et krypteringsværktøj på nettet det rigtige valg?

Folk, der søger efter et krypteringsværktøj på nettet, vil som regel en af to ting: gøre et stykke tekst til chiffertekst, de kan indsætte hvor som helst, eller få en følsom besked sikkert frem til én person. Det første er et værktøj. Det andet er en arbejdsgang, og værktøjet alene gør den ikke færdig.

En side, hvor du indsætter tekst og krypterer den, krypterer i din browser, hvis den er godt bygget, og det kan du tjekke med trinene i afsnittet om efterprøvning nedenfor. Det, den overlader til dig, er alt omkring chifferteksten: at vælge en stærk adgangssætning, sende adgangssætningen ad en separat kanal, slette chifferteksten der, hvor du indsatte den, og finde ud af, om modtageren fik den dekrypteret. Kodning er ikke kryptering, så et Base64-værktøj beskytter intet, og en svag adgangssætning er den sædvanlige måde, kryptering i browseren slår fejl på i praksis.

Et hemmeligt engangslink udfører den samme kryptering i browseren og klarer resten af arbejdsgangen: Nøglen følger med i den del af linket, der står efter #, den gemte kopi destrueres ved første åbning, linket udløber, hvis ingen åbner det, og afsenderen kan se, at indholdet er blevet vist. Til en besked til en person passer det bedre. Til chiffertekst, du selv skal gemme eller indsætte i et system, du styrer, er et lokalt værktøj som age eller GPG bedre end nogen webside, fordi nøglen slet ikke kommer i nærheden af en browser.

Hvornår ingen af dem skal bruges

Nogle hemmeligheder bør slet ikke sendes via et delingslink. Langlivede root-loginoplysninger, signeringsnøgler til produktion og store dataeksporter hører hjemme i en secret manager eller KMS med adgangsstyring, ikke i en URL. Og hvis modtageren skal bruge værdien igen og igen, er et element i en adgangskodeadministrators boks bedre end at sende links igen; levering én gang er til overdragelser, ikke til opbevaring. Hemmelige links og adgangskodeadministratorer trækker den grænse.

Sådan efterprøver du en påstand

Vælg ikke et værktøj efter, hvilket der lover mest. Vælg ud fra, hvad du forsvarer dig mod, og tjek, at det, der står på pakken, passer med arkitekturen nedenunder:

• Ligger nøglen i fragmentet? Se på linkets opbygning; nøglen skal stå efter #.
• Returnerer en almindelig hentning af linket hemmeligheden? Det må den ikke.
• Hvad gør adgangssætningen: Spærrer den for visningen, eller er den en del af nøglen?
• Hvad logges der, og oplyser operatøren det skriftligt?

LinkPilots svar står på siden om sikkerhedsarkitekturen, begrænsningerne medregnet. Den side skal tåle den samme test som alle andres.

Læs også

• Sådan virker hemmelige engangslinks
• Er OneTimeSecret sikkert?
• LinkPilot eller PrivateBin
• Hemmelige links og adgangskodeadministratorer
• Hvorfor URL'er lækker følsomme oplysninger
• Linkscannere og engangshemmeligheder

Kilder

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.