Alles wat u moet weten over Diffie-Hellman Key Exchange versus RSA

Gepubliceerd: juni 2021. Bijgewerkt: augustus 2026. Beoordeeld door het PKI-adviessteam van Encryption Consulting.

Welk probleem lost elk algoritme nu eigenlijk op?

Diffie-Hellman (DH), gepubliceerd door Whitfield Diffie en Martin Hellman in 1976, is een sleuteluitwisselingsmethode: het stelt twee partijen die elkaar nooit hebben ontmoet in staat om een ​​identiek gedeeld geheim te berekenen via een openbaar, waarneembaar kanaal, zonder dat geheim zelf ooit te verzenden. Elliptic Curve Diffie-Hellman (ECDH) past hetzelfde idee toe op elliptische kromme-wiskunde in plaats van modulaire machtsverheffing, waardoor dezelfde beveiliging wordt bereikt met veel kleinere sleutels. RSA (vernoemd naar de uitvinders, Rivest, Shamir en Adleman, 1977) lost een ander probleem op: het is een publieke sleutelversleuteling die een klein stukje data direct kan versleutelen, bekend als sleuteltransport, of een digitale handtekening kan genereren die bewijst wie een bericht heeft verzonden en dat het niet is gewijzigd.

De verwarring tussen de twee komt voort uit een naamgevingsfout: beide kwamen twintig jaar lang voor in dezelfde TLS-coderingssuite. In de "RSA-sleuteluitwisselingsmodus" verzorgde RSA het sleuteltransport, niet de sleutelovereenkomst. De client genereerde een geheim, versleutelde dit met de openbare RSA-sleutel van de server, en alleen de bijbehorende privésleutel kon het herstellen. Dit is fundamenteel anders dan bij DH/ECDH, waarbij geen van beide partijen het gedeelde geheim verzendt; elke partij berekent het lokaal op basis van zijn eigen privéwaarde en de openbare waarde van de andere partij.

De eigenschap die voor architecten het belangrijkst is, is forward secrecy, soms afgekort tot PFS (Perfect Forward Secrecy): het compromitteren van een privésleutel voor de lange termijn kan later niet worden gebruikt om eerder vastgelegde sessies te decoderen. Ephemeral DH/ECDH, meestal afgekort tot DHE of ECDHE, biedt PFS door bij elke sessie een nieuw sleutelpaar te genereren en de privésleutel direct na gebruik te verwijderen. Statisch RSA-sleuteltransport biedt dit alles niet: één gestolen privésleutel ontgrendelt elke sessie die ooit onder het bijbehorende certificaat is versleuteld. Zie onze volledige uitleg van Perfect Forward Secrecy voor de onderliggende mechanismen.

Hoe werkt Diffie-Hellman (en ECDH) nu eigenlijk?

Klassieke DH werkt met een gedeeld publiek priemgetal p en een generator g. Alice kiest een geheim geheel getal a, berekent A = g^a mod p en stuurt A. Bob kiest een geheim geheel getal b, berekent B = g^b mod p en stuurt B. Alice berekent vervolgens B^a mod p en Bob berekent A^b mod p; beiden komen uit op dezelfde waarde, g^(ab) mod p, omdat modulaire machtsverheffing commutatief is. Geen van beide partijen heeft ooit a of b verzonden, en het herstellen van a uit A, het discrete logaritme-probleem, maakt dit systeem veilig tegen een afluisteraar die beperkt is tot klassieke berekeningen.

Een eenvoudig voorbeeld maakt de mechanica concreet. Stel p = 23 en g = 5. Alice kiest a = 6 en stuurt A = 5^6 mod 23 = 8. Bob kiest b = 15 en stuurt B = 5^15 mod 23 = 19. Alice berekent 19^6 mod 23 = 2. Bob berekent 8^15 mod 23 = 2. Beiden komen uit op 2, het gedeelde geheim, zonder dat een van beide partijen 6 of 15 verzendt. In de praktijk worden priemgetallen gebruikt van minstens 2048 bits lang. RFC 7919 definieert de standaard eindige veldgroepen (ffdhe2048 en groter), juist omdat kleine voorbeelden zoals deze triviaal te kraken zijn met brute force.

ECDH past hetzelfde principe toe op punten op een elliptische curve in plaats van gehele getallen modulo een priemgetal: elke partij kiest een privé-scalar, vermenigvuldigt deze met een gedeeld basispunt om een ​​publiek punt te verkrijgen, en het gedeelde geheim is de coördinaat die wordt bereikt door beide scalars te combineren. Het probleem verschuift van de discrete logaritme van gehele getallen naar de discrete logaritme van elliptische curves, wat per bit moeilijker is. Een 256-bits curve zoals X25519 of P-256 bereikt daardoor ongeveer dezelfde klassieke beveiliging als een 3072-bits DH-groep met een eindig veld. Dat is de reden waarom TLS 1.3, moderne SSH en IKEv2/IPsec tegenwoordig standaard gebruikmaken van elliptische curve-groepen, met name X25519, in plaats van de klassieke DH-groep met een eindig veld. Voor meer informatie over curve-mathematica en de afwegingen ten opzichte van RSA, zie onze handleiding over elliptische curve-cryptografie.

Hoe werkt RSA nu precies?

Bij het genereren van een RSA-sleutel worden twee grote willekeurige priemgetallen, p en q, gekozen. Deze worden vermenigvuldigd om een ​​modulus n = p maal q te verkrijgen. Hieruit wordt een publieke exponent e (vrijwel altijd 65537) afgeleid, samen met een private exponent d, zodanig dat e maal d congruent is aan 1 modulo de totiënt van n. De publieke sleutel is (n, e); de private sleutel is (n, d). Voor sleuteltransport berekent de afzender de versleutelde tekst c = m^e mod n; alleen de houder van d kan m = c^d mod n berekenen en de oorspronkelijke waarde herstellen. Voor een handtekening verloopt het proces in omgekeerde volgorde: de ondertekenaar berekent een waarde over een hash van het bericht met behulp van de private exponent d, en iedereen die de publieke sleutel (n, e) bezit, kan deze verifiëren.

Twee dingen maken ruwe RSA in de praktijk onveilig. Ten eerste is de standaard RSA, m^e mod n zonder padding, deterministisch en structureel zwak. Daarom wordt er in de praktijk altijd padding toegevoegd: OAEP (Optimal Asymmetric Encryption Padding) voor encryptie en PSS (Probabilistic Signature Scheme) voor handtekeningen. Beide zijn gespecificeerd in PKCS#1 en opgenomen in NIST FIPS 186-5 voor handtekeningen. Ten tweede zijn de privésleutelbewerkingen van RSA, decryptie en ondertekening, rekenkundig zwaar bij moderne sleutelgroottes. NIST SP 800-57 Deel 1 Revisie 5 beoordeelt een 2048-bits RSA-sleutel op 112-bits beveiliging en een 3072-bits sleutel op 128-bits beveiliging. De kosten van modulaire machtsverheffing nemen sneller toe dan de sleutelgrootte, waardoor RSA-ondertekening consequent de traagste veelvoorkomende bewerking binnen een PKI is. Voor het volledige tijdschema voor de uitfasering en de berekende cijfers over de beveiligingssterkte, zie ons bijbehorende artikel over waar RSA nog wel en niet thuishoort.

Waarom heeft TLS 1.3 de statische RSA-sleuteluitwisseling laten vallen ten gunste van (EC)DHE?

TLS 1.2 en eerdere versies boden een cipher suite-familie aan, TLS_RSA_WITH_*, waarbij de client het pre-master secret genereerde, dit versleutelde met de RSA-publieke sleutel van de server en het vervolgens verstuurde. Dit ontwerp kent twee structurele problemen waar de industrie twintig jaar lang aan heeft gewerkt. Ten eerste is er geen forward secrecy: omdat dezelfde RSA-privésleutel elke sessie decodeert die ooit met dat certificaat is onderhandeld, legt een compromis met één sleutel, of een toekomstige kwantumcomputer die de modulus ontbindt, elke geregistreerde sessie achteraf bloot. Ten tweede is het kwetsbaar voor padding oracle-aanvallen: de aanval van Daniel Bleichenbacher uit 1998 toonde aan dat de foutmeldingen van een server op onjuist geformuleerde PKCS#1 v1.5-cipherteksten voldoende informatie lekken om een ​​versleuteld pre-master secret te achterhalen door herhaalde query's, en het ROBOT-onderzoek uit 2017 (Return Of Bleichenbacher's Oracle Threat) vond dezelfde soort kwetsbaarheid bijna twintig jaar later nog steeds exploiteerbaar in de huidige TLS-stacks van grote leveranciers.

RFC 8446, gepubliceerd in augustus 2018, heeft de statische RSA- en statische eindige-veld DH-sleuteluitwisseling volledig uit TLS 1.3 verwijderd. Elke TLS 1.3-handshake onderhandelt nu over een nieuwe (EC)DHE-sleuteluitwisseling, X25519, P-256, P-384 of een klassieke eindige-veldgroep uit RFC 7919, en gebruikt RSA (met PSS-padding) of ECDSA alleen om het handshake-transcript te ondertekenen voor authenticatie, nooit om een ​​sleutel te transporteren. Het praktische effect is dat de rol van RSA in TLS is gekrompen van twee taken naar één: het bewijzen van identiteit, niet het overdragen van geheimen. Voor een breder perspectief op hoe dit past in de algehele onderhandeling over cipher suites, zie onze inleiding tot TLS-cipher suites.

Diffie-Hellman versus RSA: Selectierichtlijnen voor architecten

Er is geen universele winnaar, omdat DH/ECDH en RSA niet uitwisselbaar zijn; de eerlijke vraag is welke taak je probeert op te lossen. Gebruik de onderstaande tabel als eerste stap en bevestig vervolgens aan de hand van de daadwerkelijk overeengekomen cipher suite of sleuteluitwisselingsmethode van het protocol, en niet alleen aan de hand van het certificaattype dat op het apparaat staat.

Eigendom	DH / ECDH	RSA
Primair doel	Uitwisseling van tijdelijke sleutels (overeenkomst over een gedeeld geheim)	Sleuteltransport (verouderd) en digitale handtekeningen/authenticatie
Voorwaartse geheimhouding	Ja, bij efemere sleutels (DHE/ECDHE); elke sessie krijgt een nieuw sleutelpaar.	Nee voor sleuteltransport; niet van toepassing op de kenmerkende rol ervan.
Prestaties	ECDH: snel, kleine sleutels (256-bits curve bereikt ongeveer de 3072-bits RSA-beveiliging); klassieke DH: trager bij grote MODP-groottes	Snelle verificatie en versleuteling van handtekeningen (kleine publieke exponent); trage ondertekening en ontsleuteling van privésleutels bij grote sleutelgroottes.
Kwantumkwetsbaarheid	Opgelost door het algoritme van Shor (discreet logaritmisch probleem, eindig veld en elliptische kromme).	Opgelost door het algoritme van Shor (probleem van de ontbinding van gehele getallen in factoren)
Typisch gebruik vandaag de dag	TLS 1.3 handshake-sleuteluitwisseling, IKEv2/IPsec VPN-groepen (RFC 7296), SSH-sleuteluitwisseling	TLS/PKI-certificaatondertekeningen, code- en firmwareondertekening, S/MIME, legacy TLS 1.2-sleuteltransport

Als vuistregel voor zowel nieuwe ontwerpen als audits geldt het volgende:

1. Gebruik efemere ECDH (X25519 of P-256) voor elk nieuw sleuteluitwisselingsontwerp; het is niet voor niets de standaard voor TLS 1.3, moderne SSH en de huidige IKEv2.
2. Gebruik RSA of ECDSA alleen voor ondertekening, of het nu gaat om een ​​TLS-certificaat, een codeondertekeningsartefact of een firmware-image, en nooit voor het transporteren van een sleutel in nieuwe ontwerpen.
3. Gebruik klassieke eindige-veld DH (RFC 7919-groepen) alleen wanneer een oudere peer geen elliptische krommen kan onderhandelen, zoals bij oudere IKEv1/IKEv2 VPN-apparatuur of embedded devices.
4. Gebruik RSA-handtekeningen alleen waar certificaatketens, hardware of clientcompatibiliteit dit vereisen; RSA-2048/3072 wordt volgens NIST SP 800-56A en FIPS 186-5 nog steeds als klassiek veilig beschouwd.
5. Beschouw elk overgebleven statisch RSA-sleuteltransport (TLS_RSA_WITH_* suites) als een bevinding die moet worden verholpen, niet als een configuratiekeuze.

Wat is het dreigingsmodel, inclusief kwantumrisico?

Klassiek gezien zijn DH en ECDH gebaseerd op het feit dat het discrete logaritme-probleem moeilijk te inverteren is, waarbij a wordt hersteld uit g^a modulo p, of een scalair uit een punt op een curve. RSA is gebaseerd op het feit dat integerfactorisatie moeilijk is, waarbij p en q worden hersteld uit n. Beide aannames zijn decennialang standgehouden tegen klassieke computers, mits geïmplementeerd met voldoende sleutelgroottes (2048-bits of grotere RSA en eindige veld DH, 256-bits of grotere elliptische curven) en correcte padding.

Kwantumcomputing doorbreekt beide aannames op dezelfde manier. Het algoritme van Peter Shor uit 1994 lost integerfactorisatie en discrete logaritmen op, inclusief de variant met elliptische krommen, in polynomiale tijd op een voldoende grote, fouttolerante kwantumcomputer. NIST IR 8547 (eerste openbare conceptversie, november 2024) stelt voor om RSA, eindige veld DH en ECC na 2030 af te schaffen en alle drie na 2035 te verbieden, juist omdat geen van deze methoden het algoritme van Shor overleeft; er is geen ontsnappingsmogelijkheid met "grotere sleutels gebruiken" zoals bij klassieke brute force-aanvallen.

De nuance die in de meeste vergelijkende analyses over het hoofd wordt gezien: forward secrecy van efemere DH/ECDH beschermt tegen één specifiek klassiek scenario, namelijk het later stelen van de langetermijnsleutel van een server, maar biedt geen bescherming tegen het risico van harvest-now-decrypt-later (HNDL). Een aanvaller die de efemere publieke waarden vastlegt die tijdens de handshake worden uitgewisseld, kan, zodra er een cryptografisch relevante kwantumcomputer bestaat, het algoritme van Shor rechtstreeks op die vastgelegde publieke waarden toepassen om het gedeelde geheim van de sessie te achterhalen, zonder dat de privésleutel van de server nodig is. RSA-sleuteltransport kent dezelfde kwetsbaarheid, maar via een andere weg: vastgelegde ciphertext plus een toekomstige, gefactoriseerde privésleutel. Noch DH/ECDH, noch RSA is op zichzelf HNDL-veilig. Daarom standaardiseren NIST en IETF hybride sleuteluitwisseling, klassieke ECDH gecombineerd met een post-kwantum sleutelinkapselingsmechanisme zoals ML-KEM (FIPS 203), als oplossing voor de korte termijn, in plaats van een grotere RSA-modulus of een grotere DH-groep.

Hoe migreert of implementeert u dit daadwerkelijk? Een praktisch proces

1. Inventariseer elk protocol en eindpunt dat nog steeds statische RSA-sleuteltransport (TLS_RSA_WITH_* cipher suites) of een specifieke DH/ECDH-configuratie onderhandelt, op TLS-servers, load balancers, VPN-concentrators en SSH-daemons.
2. Schakel RSA-sleuteltransportsuites en verouderde export- of anonieme DH-suites uit op alle plaatsen waar een scan ze detecteert; vereis minimaal ECDHE of DHE op TLS 1.2 en ga over op TLS 1.3 waar clientondersteuning dit toelaat, conform RFC 8446.
3. Standaardiseer eerst op X25519 en vervolgens op P-256 of P-384 voor FIPS-beperkte omgevingen, voor de uitwisseling van sleutels voor elliptische krommen; standaardiseer alleen op RFC 7919-groepen ffdhe2048 of groter waar krommen niet worden ondersteund.
4. Gebruik RSA- of ECDSA-certificaten alleen voor authenticatie; controleer of uw CA- en PKI-tools certificaatprofielen uitgeven die alleen handtekeningen ondersteunen, in plaats van de oudere RSA-profielen met sleutelversleuteling.
5. Voor IKEv2/IPsec VPN's kunt u overstappen van MODP Groep 1, 2 en 5 (die alle volgens RFC 8247 zijn afgekeurd) naar Groep 19, 20 of 31 (Curve25519); voor SSH heeft curve25519-sha256 de voorkeur boven diffie-hellman-group14-sha256.
6. Verplaats langetermijnsleutels voor digitale handtekeningen (RSA of ECDSA) naar HSM-opslag met geautomatiseerd levenscyclusbeheer in plaats van bestandsgebaseerde sleutels, aangezien deze sleutels een blootstellingsperiode van meerdere jaren hebben die vluchtige DH/ECDH-sleutels niet hebben.
7. Test de hybride sleuteluitwisseling (X25519 gecombineerd met ML-KEM, volgens de opkomende IETF-concepten voor hybride TLS-sleuteluitwisseling) eerst op het verkeer met de hoogste waarde en de langste vertrouwelijkheidsperiode, ruim vóór een eventuele harde NIST-deadline.

Wat zijn de afwegingen tussen prestaties en interoperabiliteit?

De prestaties van wiskunde met elliptische krommen zijn vrijwel overal beter. Het genereren van ECDH-sleutels en het berekenen van gedeelde geheimen zijn zo efficiënt dat ze bij elke TLS-handshake kunnen worden uitgevoerd zonder merkbare vertraging aan de clientzijde. Bovendien biedt een 256-bits kromme dezelfde klassieke beveiliging als een 3072-bits RSA- of eindige-veld DH-sleutel, terwijl er slechts ongeveer een twaalfde van de hoeveelheid data over de lijn wordt verzonden. De asymmetrie van RSA werkt de andere kant op: het verifiëren van een handtekening of het versleutelen met de kleine publieke exponent (65537) is snel, maar het ondertekenen of ontsleutelen met de private exponent wordt aanzienlijk trager naarmate de sleutelgrootte toeneemt van 2048 naar 3072 en verder. Dit is van belang voor elke server die grote hoeveelheden handtekeningen verwerkt, zoals een certificeringsinstantie (CA) of een OCSP-responder.

Interoperabiliteit is waar klassieke DH en RSA nog steeds hun waarde bewijzen. Sommige embedded apparaten, oudere netwerkapparaten en lang meegaande industriële besturingssystemen implementeren alleen eindige veld-DH of RSA en kunnen niet worden gepatcht om elliptische krommen te ondersteunen zonder een hardware-update. Overheidsinstellingen en FIPS-gereguleerde omgevingen kunnen NIST-goedgekeurde krommen (P-256, P-384) verplichten boven X25519, met name omdat X25519 niet was opgenomen in oudere FIPS 140-validatielijsten, hoewel FIPS 140-3-modules er steeds vaker ondersteuning voor bieden. Elk migratieplan moet deze gevallen behandelen als een gedocumenteerde, tijdsgebonden uitzonderingslijst, en niet als reden om RSA-sleuteltransport of 1024-bits DH standaard ingeschakeld te laten in het gehele netwerk.

Welke belangrijke beheersafhankelijkheden creëert elk van deze maatregelen?

DH en ECDH zelf creëren vrijwel geen last voor het beheer van sleutels op de lange termijn: er bestaan ​​tijdelijke privésleutels voor één handshake die vervolgens worden verwijderd, dus er is niets om te roteren, in bewaring te geven of in te trekken. De afhankelijkheid die ze wel creëren, is die van de ondertekeningssleutel die wordt gebruikt om de uitwisseling te authenticeren, een RSA- of ECDSA-certificaat, zonder welke een DH/ECDH-handshake kwetsbaar is voor een man-in-the-middle-aanval waarbij de publieke waarden worden vervangen door die van de tegenstander.

RSA creëert het tegenovergestelde profiel: een langlevende privésleutel die moet worden gegenereerd, opgeslagen, geroteerd en uiteindelijk ingetrokken voor elk certificaat in de keten, van blad tot root. Dat is een probleem dat de volledige levenscyclus van een certificaat omvat: sleutelgeneratie binnen een HSM of een vergelijkbare beveiligde omgeving, uitgifte en verlenging vóór vervaldatum, controle op intrekking (OCSP of CRL) die daadwerkelijk bereikbaar is voor de vertrouwende partijen, en veilige vernietiging aan het einde van de levensduur. Een enkele slecht beheerde RSA-rootsleutel, of dit nu komt door een zwakke generatie, vertraagde rotatie of een onbereikbaar intrekkingspunt, maakt elk certificaat dat eronder is uitgegeven ongeldig. Dit is precies het operationele aspect dat CertSecure Manager automatiseert: ontdekking, uitgifte, verlenging en intrekking van een gemengd RSA/ECDSA-certificatenportfolio, ondersteund door HSM-beveiligde sleutelopslag.

Beperkingen

• NIST IR 8547 is nog steeds een eerste openbaar ontwerp; de data voor afschrijving in 2030 en uitsluiting in 2035 voor RSA, DH en ECC zijn voorstellen, geen definitieve datums, en kunnen na openbare raadpleging nog wijzigen.
• De in dit artikel gebruikte beveiligingssterktecijfers (2048-bits RSA met 112-bits beveiliging, X25519 met ongeveer 128-bits beveiliging) zijn afkomstig uit NIST SP 800-57 Deel 1 Revisie 5 en gaan uit van een correcte implementatie; een slecht gegenereerde sleutel of een ontbrekend opvulschema ondermijnt beide algoritmen, ongeacht de grootte.
• Hybride sleuteluitwisseling, een combinatie van klassieke en PQC-sleutels, is nog in ontwikkeling binnen de IETF-concepten en implementaties van leveranciers; de ondersteuning in productieomgevingen verschilt per TLS-bibliotheek en is nog niet universeel.
• Dit artikel vergelijkt DH/ECDH en RSA als algoritmefamilies; het behandelt geen symmetrische cijfers zoals AES, hashfuncties of de post-kwantum handtekeningalgoritmen (ML-DSA, SLH-DSA) die uiteindelijk RSA- en ECDSA-handtekeningen zullen vervangen.

Wat zou Encryption Consulting aanbevelen?

Onze standaardaanbeveling voor een volledig nieuw ontwerp is ondubbelzinnig: onderhandel over de sleuteluitwisseling met efemere ECDH (eerst X25519, daarna P-256 voor FIPS-omgevingen) en reserveer RSA of ECDSA uitsluitend voor ondertekening. We beschouwen dit niet als een discussie die per project opnieuw moet worden gevoerd; het moet een vaststaande architectuurkeuze zijn die wordt afgedwongen in uw TLS-configuratie en CA-certificaatprofielen, en niet een keuze per team.

Waar wij klanten meer onder druk zetten dan de meeste vergelijkende analyses, is op twee punten. Ten eerste: beschouw forward secrecy niet als een kwantummitigatie; we zien regelmatig dat teams het ECDHE-vakje aanvinken in een TLS-scan en het kwantumrisico als opgelost beschouwen, terwijl de HNDL-blootstelling in feite identiek is, ongeacht of de handshake gebruikmaakt van RSA-sleuteltransport of ECDHE, zodra er een cryptografisch relevante kwantumcomputer bestaat. Ten tweede: laat de DH-versus-RSA-beslissing niet alleen op protocolniveau plaatsvinden; deze moet gekoppeld worden aan een certificaatlevenscyclusprogramma, omdat een elegante ECDHE-handshake, geauthenticeerd door een onbeheerde, niet-geroteerde RSA-rootsleutel, nog steeds een single point of failure vormt.

In de praktijk betekent dit dat drie dingen samenwerken: een PKI-beoordeling om alle plekken te vinden waar nog steeds statische RSA-sleuteltransport of verouderde DH-groepen worden gebruikt, CertSecure Manager om het resterende RSA- en ECDSA-certificatenbestand onder geautomatiseerd, door HSM ondersteund lifecyclebeheer te brengen, en een PQC-adviesopdracht om hybride ECDH-plus-ML-KEM-pilots te plannen voor het verkeer dat daadwerkelijk tientallen jaren vertrouwelijkheid vereist, in plaats van te proberen een deadline van 2030 te halen die nog steeds een concept is.

Conclusie

Diffie-Hellman en RSA zijn geen rivalen die om dezelfde taak strijden; het zijn complementaire primitieven die TLS 1.3, IKEv2 en SSH nu bewust combineren: efemere (EC)DHE voor het gedeelde geheim en RSA of ECDSA voor de handtekening die bewijst met wie je communiceert. De architectonische fout die gecorrigeerd moet worden, is niet de keuze voor het verkeerde algoritme; het is het ingeschakeld laten van statisch RSA-sleuteltransport ergens in een omgeving die verder is overgestapt op ECDHE, of het onbeheerd laten van een ondertekeningssleutel omdat de handshake eromheen modern lijkt. Zorg voor een goede inventarisatie, een correcte configuratiebasislijn en een goed certificaatlevenscyclusprogramma, en de kwantumtransitie wordt een geplande migratie in plaats van een noodsituatie.

Veelgestelde Vragen / FAQ

Is Diffie-Hellman veiliger dan RSA? Niet veiliger in de zin van een sterkere aanname over de moeilijkheidsgraad; ze zijn gebaseerd op verwante maar verschillende moeilijke problemen, discrete logaritme versus integerfactorisatie, die bij gelijke sleutelgroottes als vergelijkbaar sterk worden beschouwd. DH/ECDH is de betere keuze voor sleuteluitwisseling omdat efemere sleuteluitwisseling forward secrecy biedt, iets wat RSA-sleuteltransport niet kan bieden.

Kunnen RSA en Diffie-Hellman samen worden gebruikt? Ja, en dit is het standaardontwerp van TLS 1.2 en TLS 1.3: ECDHE of DHE onderhandelt over het gedeelde geheim van de sessie, terwijl RSA (of ECDSA) de handshake ondertekent om de server te authenticeren. De twee algoritmen voeren dus verschillende taken uit binnen dezelfde verbinding in plaats van met elkaar te concurreren.

Is Diffie-Hellman kwantumresistent? Nee. Zowel de klassieke DH als ECDH zijn gebaseerd op het discrete logaritme-probleem, dat Shors algoritme in polynomiale tijd oplost op een voldoende krachtige kwantumcomputer, precies zoals het factorisatieprobleem van RSA. Geen van beide is kwantumresistent; ML-KEM (FIPS 203) is de door NIST gestandaardiseerde kwantumresistente vervanging voor sleuteluitwisseling.

Waarom ondersteunt TLS 1.3 geen RSA-sleuteluitwisseling meer? Omdat statisch RSA-sleuteltransport geen forward secrecy heeft en de oorzaak was van de Bleichenbacher- en ROBOT-padding-orakelaanvallen; RFC 8446 heeft dit volledig verwijderd en vereist efemere (EC)DHE voor elke TLS 1.3-handshake, waardoor RSA alleen nog beschikbaar is om de handshake te ondertekenen voor authenticatie.

Moeten we in 2026 nog steeds nieuwe RSA-certificaten genereren? Ja, voor ondertekening en authenticatie waar ECDSA nog niet door elke client in het netwerk wordt ondersteund, met een sleutel van minimaal 2048 bits, bij voorkeur 3072 bits, met PSS-padding conform FIPS 186-5. Nieuwe ontwerpen zouden standaard ECDSA of Ed25519 moeten gebruiken voor ondertekeningen en het genereren van RSA-certificaten moeten reserveren voor uitzonderingen die gebaseerd zijn op compatibiliteit, en die worden bijgehouden aan de hand van de NIST IR 8547-tijdlijn.

Referenties

• RFC 8446, Het Transport Layer Security (TLS) Protocol Versie 1.3: https://www.rfc-editor.org/rfc/rfc8446
• RFC 7296, Internet Key Exchange Protocol Versie 2 (IKEv2): https://www.rfc-editor.org/rfc/rfc7296
• RFC 8247, Implementatievereisten voor algoritmen en gebruiksrichtlijnen voor IKEv2: https://www.rfc-editor.org/rfc/rfc8247
• RFC 7919, Onderhandelde eindige veld Diffie-Hellman efemere parameters voor TLS: https://www.rfc-editor.org/rfc/rfc7919
• NIST SP 800-56A Revisie 3, Aanbeveling voor paarsgewijze sleuteluitwisselingsschema's met behulp van discrete logaritme-cryptografie: https://csrc.nist.gov/pubs/sp/800/56/a/r3/final
• NIST FIPS 186-5, Digitale handtekeningstandaard (DSS): https://csrc.nist.gov/pubs/fips/186-5/final
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
• NIST SP 800-57 Deel 1 Revisie 5, Aanbeveling voor sleutelbeheer: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r5.pdf
• NIST IR 8547 (eerste openbare conceptversie, november 2024), Overgang naar post-kwantumcryptografiestandaarden: https://csrc.nist.gov/pubs/ir/8547/ipd
• IANA, Internet Key Exchange Version 2 (IKEv2) Parameters: https://www.iana.org/assignments/ikev2-parameters
• ROBOT-aanval (terugkeer van Bleichenbachers Oracle-dreiging), 2017: https://robotattack.org/
• Gidney en Ekera (2019), Hoe je 2048-bits RSA-getallen in 8 uur kunt ontbinden met behulp van 20 miljoen ruisende qubits: https://arxiv.org/abs/1905.09749