Hvad er Diffie-Hellman kryptering—og hvad er det ikke?

Diffie-Hellman (DH) er en metode til at lave en fælles hemmelighed mellem to parter, selvom de kommunikerer over en kanal, som andre kan lytte til. Pointen er, at ingen af parterne behøver at sende den endelige hemmelighed direkte. I praksis bruges DH typisk som en del af en større protokol til at etablere nøgler, der senere bruges til at kryptere data.

Det er vigtigt at skelne mellem tre ting: (1) nøgleaftale (aftale om en fælles hemmelighed), (2) kryptering (beskyttelse af selve dataene) og (3) autentificering (sikring af identitet). Diffie-Hellman dækker primært (1) nøgleaftalen. Uden passende autentificering kan en angriber i nogle situationer påvirke hvilken “modpart” der aftales med, selv om nøgleaftalen matematisk set gennemføres.

Et simpelt model: To parter “møder” en fælles hemmelighed uden at sende den

Forestil dig to personer, der vil få samme hemmelige værdi:

  • Begge vælger hver deres hemmelige tal (private værdier).
  • De sender nogle beregnede offentligheder baseret på de private tal og på fælles, offentlige parametre.
  • Den ene part kan bruge den andens offentlighed sammen med sin egen private værdi til at beregne den fælles hemmelighed.
  • Den anden part gør det samme—og ender med samme hemmelighed.

Nøglen her er, at den offentlige information ikke er nok til at udlede den private hemmelighed, når man antager, at det underliggende matematiske problem er “svært” for en udenforstående. Det er dog netop en forudsætning: sikkerheden afhænger af valg af parametre og af, hvordan metoden integreres i den protokol, der bruger DH.

Hvorfor det kan give en “ny dimension” af sikkerhed

DH kan forbedre sikkerheden i forhold til løsninger, hvor den samme nøgle eller et nøglemateriale skulle udveksles direkte. Når nøgleaftalen sker på en måde, der ikke kræver at hemmeligheden sendes, bliver det sværere for en passiv lytter at udlede nøglerne ud fra de observerbare data.

Derudover kan nogle varianter af DH understøtte, at nøgler ændres ofte (fx ved sessioner), så historiske data ikke nødvendigvis kan kompromitteres, hvis en nøgle fra en senere situation bliver kendt. Den præcise effekt afhænger af, hvilken variant og opsætning der er tale om.

Samtidig er det afgørende at forstå, at “hemmeligholdelse af nøgler” ikke automatisk betyder beskyttelse mod alle trusler. Hvis der mangler autentificering, kan en aktiv angriber i visse scenarier forsøge at ændre, hvem der reelt kommunikeres med.

Centrale forskelle: nøgleaftale vs. kryptering vs. autentificering

Når nogen siger “Diffie-Hellman kryptering”, kan det lyde som om metoden i sig selv krypterer data. Men i de fleste sammenhænge er DH primært nøgleaftalen.

  • Nøgleaftale (DH): skaber fælles nøglemateriale.
  • Kryptering: bruger nøglen til at gøre indholdet uforståeligt for uvedkommende.
  • Autentificering: sikrer, at man faktisk taler med den rigtige part.

Et praktisk tjekpunkt er derfor: Hvilken del af sikkerhedsmål opnår du? DH hjælper især med at etablere nøgler sikkert over en åben kanal. Men “fuld sikkerhed” i en hel forbindelse kræver, at protokollen også håndterer autentificering og et passende krypteringssetup.

Undtagelser og begrænsninger, der kan ændre betydningen af DH

Selv om DH er et veletableret koncept, påvirker flere ting, om gevinsten bliver reel:

  1. Parametre og implementering Hvis protokollen bruger svage eller dårligt valgte parametre, kan det reducere sikkerheden. Fordi detaljer afhænger af implementering og version, kan man ikke udlede den faktiske styrke kun ud fra navnet “Diffie-Hellman”.

  2. Samspil med autentificering Hvis kommunikationen etableres uden at parterne kan verificere hinandens identitet, kan en aktiv angriber i princippet påvirke forbindelsen (selve nøgleaftalen kan stadig forløbe, men identitetsbindingen kan mangle). Derfor skal man se på helheden i protokollen.

  3. Trusselsmodellen DH hjælper ofte primært mod passive aflyttere, der ønsker at læse trafikken. Hvis truslen i stedet handler om manipulation, spoofing eller andre aktive angreb, kræver løsningen andre sikkerhedslag.

Sådan kan du kontrollere, om DH faktisk bruges meningsfuldt

Du kan ikke altid få hele billedet fra overskrifter—men du kan stille konkrete kontrolspørgsmål:

  • Bruges der DH som del af en nøgleaftale i den aktuelle forbindelse, eller er det kun kryptering uden DH?
  • Er der tegn på, at der er autentificering (fx at modpartens identitet verificeres via en tillidsmekanisme i den protokol, du bruger)?
  • Hvilken “variant” af nøgleaftalen anvendes, og hvor ofte skiftes nøgler (sessioner)?
  • Stemmer trusselsmodellen med din forventning? Hvis du især vil modstå aflytning, er nøgleaftalen relevant; hvis du vil modstå aktiv manipulation, skal autentificering og protokolbeskyttelse også være på plads.

Hvis du arbejder med TLS eller lignende i en browser eller app, kan tekniske oplysninger ofte indikere, hvilken nøgleaftalekomponent der er i spil, men detaljen kan være afhængig af klient, server og opsætning. Vær derfor opmærksom på, at “DH i teorien” ikke er det samme som “DH i den konkrete konfiguration”.