Definition og formål

Diffie-Hellman-kryptering (mere præcist: Diffie–Hellman-nøgleudveksling) er en teknik til, at to parter kan blive enige om en fælles hemmelig nøgle, selv når de kommunikerer over en kanal, som en tredjepart kan lytte med på. Pointen er, at selve den fælles hemmelighed ikke sendes direkte.

Efter en vellykket nøgleudveksling kan den fælles hemmelige nøgle typisk bruges som grundlag for efterfølgende symmetrisk kryptering af selve data (fx via en kombination af nøgleafledningsfunktioner og en skabelon for, hvordan der dannes sessionnøgler). I praksis fungerer Diffie–Hellman ofte som “motoren” bag sikre sessioner, ikke som en direkte metode til at kryptere et vilkårligt dokument alene.

Et simpelt modelbillede: aftal hemmelighed uden at dele den

Forestil dig to deltagere, A og B, som vil have samme hemmelige nøgle. De vælger hver især en hemmelig “privat” værdi og kombinerer den med offentlige parametre, som begge parter kender. Resultatet bliver offentlige mellemregninger, som de kan dele åbent.

Når A sender sin offentlige mellemregning til B, og B sender sin til A, kan hver part beregne den samme fælles hemmelige værdi ved hjælp af sin egen private værdi og den andens offentlige mellemregning. En eavesdropper, der blot ser de åbne beskeder og de offentlige parametre, har ikke den private værdi og kan derfor ikke (med passende opsætning) genskabe den hemmelige nøgle.

Vigtigt: Diffie–Hellman handler om nøgleaftale. Selve “hemmeligheden” bliver først til brugbar sikkerhed, når den kobles sammen med resten af protokollen (typisk kryptering, integritet og ofte autentificering).

Hvor passer Diffie–Hellman ind, og hvad består “sikkerheden” af?

Diffie–Hellman kan indgå i flere kryptografiske protokoller. I mange moderne systemer ses det som en del af en nøgleudveksling, der senere muliggør en sikker session. Sikkerheden afhænger dog af flere lag:

  1. Valg af kryptografisk variant og parametre: Ikke alle parametre og implementeringer er lige robuste. Moderne varianter (fx ellip tiske kurver, ofte kaldet ECDH) er almindelige, fordi de kan give gode sikkerhedsegenskaber med mindre nøgler end ældre tilgange.

  2. Korrekt implementering: Selve ideen er én ting; at implementere den rigtigt (inkl. korrekt brug af tilfældighed, håndtering af nøgler og undgåelse af lækager) er afgørende. Små fejl kan i praksis svække sikkerheden.

  3. Autentificering og beskyttelse mod MITM: Diffie–Hellman i sin rene nøgleaftaleform forhindrer ikke nødvendigvis, at en aktiv angriber omsætter kommunikationen. Hvis parterne ikke kan bevise, hvem de er over for hinanden, kan en man-in-the-middle (MITM) i teorien etablere separate nøgleaftaler med hver part. Protokoller løser typisk dette ved at kombinere nøgleudvekslingen med autentificering (fx via certifikater, signaturer eller andre identitetsmekanismer).

Derfor er det ikke korrekt at læse Diffie–Hellman som en “magi-lås”, der altid giver end-to-end sikkerhed alene. Det er en byggeklods, hvis værdi afhænger af, hvordan den bruges.

Forskelle og grænser: hvad du bør nuancere

Selv om mange forbinder “Diffie-Hellman-kryptering” med høj sikkerhed, er der vigtige grænser, som kan ændre den praktiske effekt:

  • Nøgleaftale vs. datakryptering: Diffie–Hellman giver en fælles hemmelig nøgle, men data bliver typisk krypteret (og sikret mod ændringer) af algoritmerne, der bruger den nøgle. Hvis resten af protokollen er svag, kan sikkerheden stadig være begrænset.

  • Ældre varianter og parametre: Hvis en løsning bruger for svage eller forældede parametre, kan sikkerheden blive ringere. Omvendt er det netop derfor, moderne systemer ofte vælger nyere varianter og strammere parametervalg.

  • Aktive angreb uden autentificering: Uden mekanismer til at verificere modpartens identitet kan en angriber forsøge at omdirigere nøgleaftalen. Dette er et centralt punkt, fordi det flytter fokus fra “kan jeg høre?” til “kan jeg påvirke samtalen?”

  • Implementeringsdetaljer: Spørgsmål om tilfældighed (randomness) og korrekt nøglehåndtering er ikke teoretiske hjørnesager. De kan afgøre, om den forventede sikkerhed faktisk opnås.

Praktisk: sådan kan du kontrollere om Diffie–Hellman bidrager godt

Du behøver ikke være kryptograf for at vurdere kvaliteten af nøgleudvekslingen. Du kan i stedet se efter kontrolpunkter i de oplysninger, som systemet eller klienten kan vise:

  1. Hvilken nøgleudvekslingsmetode bruges: Er det en moderne Diffie–Hellman-variant, fx ECDH? Nogle systemer viser tydeligt hvilken algoritme de bruger til key exchange.

  2. Om forbindelsen også har autentificering: Kan klienten verificere serverens identitet (typisk via certifikater eller signaturer)? Hvis autentificering mangler, bør du være mere forsigtig med at antage, at sikkerheden er intakt mod aktive angreb.

  3. Om der er “forward secrecy”: Mange moderne protokoller bruger Diffie–Hellman på en måde, så kompromittering af en fremtidig nøgle ikke automatisk afslører tidligere sessioner. Om det er tilfældet afhænger af protokollens konkrete konfiguration og hvordan nøglematerialet håndteres.

  4. Helheden i kryptopakken: Selv en korrekt Diffie–Hellman-nøgleaftale skal understøttes af stærke efterfølgende valg til kryptering og integritet.

Usikkerhed at holde sig for øje: Uden at kende den konkrete protokol og opsætning kan man ikke konkludere sikkert, hvordan Diffie–Hellman påvirker din konkrete risiko. Diffie–Hellman kan være en stærk del af en løsning, men kun når resten af systemet bruger den rigtigt og kombinerer den med autentificering og robuste krypteringsvalg.