Inzicht in elliptische curve-cryptografie (ECC)

Elliptische-kromme-cryptografie (ECC) is een vorm van publieke-sleutelcryptografie gebaseerd op de algebraïsche structuur van elliptische krommen over eindige velden. Het bereikt dezelfde beveiligingsdoelen als RSA , waaronder sleuteluitwisseling, digitale handtekeningen en authenticatie, met aanzienlijk kleinere sleutelgroottes, snellere bewerkingen en een lager resourceverbruik. Een 256-bits ECC-sleutel biedt ongeveer dezelfde beveiliging als een 3072-bits RSA-sleutel. De aanbevolen actie: gebruik ECDSA P-256 of Ed25519 voor nieuwe digitale handtekeningen en TLS-certificaten, ECDHE voor sleuteluitwisseling in TLS 1.3, en begin met het plannen van de migratie naar post-quantum alternatieven (ML-KEM, ML-DSA) voor langlopende infrastructuren waar de uitfasering in 2030 van toepassing is.

Kort antwoord: Wat is ECC en wanneer moet je het gebruiken?

ECC is het geprefereerde asymmetrische cryptografische algoritme voor de meeste nieuwe implementaties: TLS-certificaten, codeondertekening, SSH-sleutels en authenticatie voor mobiele apparaten/IoT. De beveiliging ervan is gebaseerd op het Elliptic Curve Discrete Logarithm Problem (ECDLP), dat geen bekende sub-exponentiële oplossing heeft op een goed gekozen curve. Voordeel van de sleutelgrootte: ECDSA P-256 biedt 128-bits beveiliging met een sleutel van 32 bytes; RSA vereist een sleutel van 3072 bits (384 bytes) voor een vergelijkbare beveiliging. Gebruik ECC voor nieuwe certificaten, SSH-sleutels en codeondertekening. Gebruik RSA alleen waar ECC niet wordt ondersteund door oudere systemen. Let op: ECC is niet kwantumveilig; het algoritme van Shor doorbreekt ECDLP. Plan de migratie naar NIST-gestandaardiseerde post-kwantumalgoritmen voor infrastructuren met een sleutellevensduur van meerdere jaren.

Wat is elliptische curve-cryptografie (ECC)?

ECC is een vorm van publieke-sleutelcryptografie waarbij je twee wiskundig verwante sleutels hebt: een openbare sleutel die je deelt en een privésleutel die je geheim houdt. Wat ECC uniek maakt, is het gebruik van elliptische krommen: wiskundige structuren gedefinieerd over eindige velden door een vergelijking van de vorm y² = x³ + ax + b . Wiskundigen bestudeerden deze krommen al eeuwen, maar in 1985 ontdekten Neal Koblitz en Victor S. Miller onafhankelijk van elkaar hun toepassing in de cryptografie, waardoor sterke beveiliging mogelijk werd met veel kleinere sleutels dan eerdere benaderingen zoals RSA.

De veiligheid van ECC berust op het Discrete Logaritme Probleem van Elliptische Curven (ECDLP) : gegeven een basispunt G op de curve en een resulterend punt P, berekend als P = kG (door middel van scalaire vermenigvuldiging, waarbij G herhaaldelijk k keer bij zichzelf wordt opgeteld volgens de regels van de curve), is het computationeel onhaalbaar om k te vinden gegeven alleen G en P. Er is geen bekend algoritme dat ECDLP significant sneller oplost dan brute force op een goed gekozen curve, en daarom bieden kleine ECC-sleutels een sterke beveiliging.

Hoe werkt de ECDH-sleuteluitwisseling?

ECDH (Elliptic Curve Diffie-Hellman) is het sleuteluitwisselingsprotocol dat is gebaseerd op ECC. Het stelt twee partijen in staat om een ​​gedeeld geheim vast te stellen via een onbeveiligd kanaal zonder het geheim zelf te verzenden. Hieronder een voorbeeld met Alice en Bob:

Alice en Bob spreken publiekelijk een specifieke elliptische curve af en een startpunt G op die curve. Alice kiest een geheim getal a (haar privésleutel) en berekent haar publieke sleutel A = aG (scalaire vermenigvuldiging van G met a). Bob kiest een geheim getal b (zijn privésleutel) en berekent zijn publieke sleutel B = bG. Beiden wisselen hun publieke sleutels A en B openlijk uit.

Alice berekent het gedeelde geheim: aB = a(bG) = abG. Bob berekent hetzelfde gedeelde geheim: bA = b(aG) = abG. Beiden komen uit op hetzelfde punt abG op de curve, wat het gedeelde geheim wordt. Een afluisteraar die G, A en B observeert, kan het gedeelde geheim abG niet berekenen zonder ECDLP op te lossen, dat wil zeggen, zonder a te vinden uit G en A, of b uit G en B, wat computationeel onhaalbaar is.

In de praktijk genereert ECDHE (Ephemeral ECDH) voor elke sessie een nieuw sleutelpaar, waarna de tijdelijke privésleutels worden verwijderd. Dit zorgt voor forward secrecy : het compromitteren van de langetermijnsleutels kan later geen eerdere sessies decoderen, omdat de tijdelijke sessiesleutels verdwenen zijn. TLS 1.3 vereist ECDHE voor alle sleuteluitwisselingen, waardoor forward secrecy verplicht is. Zie onze handleiding over TLS 1.2 en TLS 1.3 voor meer informatie over de praktische toepassing hiervan.

ECC versus RSA

Zowel RSA als ECC bereiken de doelstellingen van publieke-sleutelcryptografie, maar via verschillende wiskundige grondslagen. RSA is gebaseerd op de moeilijkheid om grote gehele getallen te ontbinden in factoren; ECC is gebaseerd op ECDLP. De praktische verschillen zijn aanzienlijk:

Kenmerk	RSA	ECC
Beveiliging gebaseerd op	Factorisatie van gehele getallen	Elliptische kromme discrete logaritmeprobleem (ECDLP)
Sleutelgrootte voor 128-bits beveiliging	3072 beetjes	256 bits (ECDSA P-256)
Sleutelgrootte voor 192-bits beveiliging	7680 beetjes	384 bits (ECDSA P-384)
Ondertekeningsprestaties	Langzame (grote modulaire machtsverheffing)	Snel
Verificatieprestaties	Snel	Snel
Impact van de certificaatgrootte	Groot (RSA-3072-certificaat, openbare sleutel circa 384 bytes)	Klein (ECDSA P-256 certificaat ~32 bytes voor de publieke sleutel)
Meest geschikt voor	Verouderde systemen die RSA-compatibiliteit vereisen	Nieuwe implementaties: TLS, SSH, codeondertekening, IoT, mobiel
Kwantumveiligheid	Niet kwantumveilig (Shor's algoritme is in strijd met RSA)	Niet kwantumveilig (Shor's algoritme doorbreekt ECDLP)

Vergelijking van de beveiligingssterkte van verschillende algoritmefamilies

NIST SP 800-57 Deel 1 Rev. 5 definieert equivalente beveiligingsniveaus voor symmetrische, ECC- en RSA-algoritmen. Dit stelt beveiligingsarchitecten in staat om algoritmen te kiezen die een gelijkwaardige bescherming bieden zonder onnodig hoge rekenkosten.

Beveiligingssterkte (bits)	Symmetrische sleutelgrootte	ECC-sleutelgrootte	RSA-sleutelgrootte
128	AES-128	256-283 bits (P-256)	3072 beetjes
192	AES-192	384-511 bits (P-384)	7680 beetjes
256	AES-256	512+ bits (P-521)	15360 beetjes

ECC biedt dezelfde beveiliging als RSA, maar met aanzienlijk kleinere sleutels. Voor de meest voorkomende implementatiedoelstelling van 128-bits beveiliging: ECDSA P-256 (publieke sleutel van 32 bytes) versus RSA-3072 (publieke sleutel van 384 bytes). Dit verschil in grootte is van groot belang voor de grootte van TLS-certificaten, de grootte van DNSSEC-reacties en apparaten met beperkte resources. Het voordeel van ECC komt het best tot uiting in omgevingen waar bandbreedte, opslag of rekenkracht beperkt zijn: mobiele applicaties, IoT-apparaten , smartcards en embedded systemen.

Richtlijnen voor het ECC-algoritme en de curvekeuze

Gebruik geval	Aanbevolen ECC-algoritme/curve	Waarom	vermijden
TLS-certificaten (nieuwe implementaties)	ECDSA P-256	128-bits beveiliging; breed ondersteund; kleinere certificaten verkleinen de TLS-handshakegrootte; NIST SP 800-52 Rev. 2 aanbevolen	RSA-2048 (voorgesteld, na 2030 afgeschaft volgens NIST IR 8547)
TLS-sleuteluitwisseling (sessiesleutels)	ECDHE X25519 of P-256	Ephemeral key exchange biedt forward secrecy; TLS 1.3 vereist ECDHE voor alle verbindingen.	RSA-sleuteluitwisseling (geen forward secrecy; verwijderd uit TLS 1.3)
SSH-sleutels	Ed25519	Edwards-curve DSA; 128-bits beveiliging; 32-byte publieke sleutel; snel; bestand tegen timing side-channel-aanvallen; ondersteund door OpenSSH 6.5+.	DSA (verouderd); RSA-1024 (onveilig); ECDSA P-256 (aanvaardbaar alternatief indien Ed25519 niet beschikbaar is)
Code ondertekening	ECDSA P-256 of P-384	Kleinere handtekeningen dan RSA met gelijkwaardige beveiliging; sneller ondertekenen; belangrijk voor ondertekeningsprocessen met een hoge doorvoer.	RSA-1024 (onveilig); SHA-1 als hash (onbetrouwbaar)
DNSSEC-zoneondertekening	ECDSA P-256	Kleinere signatures passen gemakkelijker in DNS UDP-reacties; kleinere zonegrootte	RSA-1024 (onveilig); RSA-2048 (aanzienlijk grotere handtekeningen)
Mobiele en IoT-authenticatie	ECDSA P-256 of Ed25519	Lagere reken-, energie- en bandbreedtevereisten in vergelijking met RSA bij gelijkwaardige beveiliging.	RSA-3072+ (hogere rekenbelasting op hardware met beperkte mogelijkheden)
Post-kwantummigratie (sleuteluitwisseling)	ML-KEM (FIPS 203)	NIST-gestandaardiseerde PQC-vervanging voor ECDH; bestand tegen het algoritme van Shor	ECDH alleen al voor nieuwe, duurzame infrastructuur

Voordelen en nadelen van ECC

Voordelen van ECC

• Kleinere sleutelgrootte met gelijkwaardige beveiliging: ECC behaalt 128-bits beveiliging met een 256-bits sleutel, vergeleken met 3072 bits voor RSA. Kleinere sleutels verminderen de opslagbehoefte, de bandbreedte voor certificaatoverdracht en de rekentijd.
• Sterke wiskundige basis: Er bestaat geen bekende subexponentiële aanval tegen ECDLP op zorgvuldig gekozen krommen. Dit biedt robuuste beveiliging zonder afhankelijk te zijn van algoritme-onduidelijkheid.
• Voorwaartse geheimhouding via ECDHE: ECDHE maakt de uitwisseling van tijdelijke sleutels mogelijk en biedt forward secrecy, zodat het compromitteren van langetermijnsleutels geen eerdere sessies blootlegt.
• Prestaties op hardware met beperkte mogelijkheden: Kleinere sleutelformaten verlagen direct de rekenlast voor cryptografische bewerkingen, waardoor ECC de praktische keuze is voor mobiele apparaten, IoT-sensoren en smartcards.

Nadelen van ECC

• De curvekeuze is cruciaal: De beveiliging van ECC is sterk afhankelijk van de keuze van wiskundig verantwoorde curveparameters. Zwakke of slecht gekozen curves kunnen kwetsbaarheden introduceren die de beveiligingsgaranties ondermijnen. Gebruik uitsluitend NIST-gestandaardiseerde curves (P-256, P-384, P-521) of breed getoetste alternatieven (X25519, Ed25519).
• Niet kwantumveilig: Het algoritme van Shor op een kwantumcomputer breekt ECDLP. ECC moet worden gemigreerd naar post-kwantumalgoritmen (ML-KEM, ML-DSA) voor een duurzame infrastructuur.
• Compatibiliteitsproblemen met oudere versies: Oudere systemen, embedded devices en bepaalde enterprise middleware ondersteunen mogelijk geen ECC. De RSA-compatibiliteit is breder voor legacy brownfield-omgevingen.
• Implementatie complexiteit: ECC-implementaties moeten zorgvuldig omgaan met randgevallen in curve-rekenkunde (wijzen naar oneindigheid, ongeldige validatie van de publieke sleutel) om side-channel-kwetsbaarheden te voorkomen. Gebruik beproefde cryptografische bibliotheken in plaats van eigen implementaties.

Toepassingen van elliptische krommecryptografie

1. Digitale handtekeningen en codeondertekening: ECDSA ondertekent documenten, softwareversies en firmware-updates om de authenticiteit te verifiëren en manipulatie te detecteren. Kleinere handtekeningen en snellere ondertekening maken het een aantrekkelijkere keuze dan RSA voor codeondertekeningsprocessen met een hoge doorvoer.
2. Beveiliging van webverbindingen (HTTPS/TLS): ECDSA P-256 TLS-certificaten authenticeren servers. ECDHE zorgt voor de uitwisseling van de forward-secret key tijdens de TLS-handshake. Kleinere ECC-certificaten verkorten de tijd die nodig is om een ​​verbinding tot stand te brengen, wat vooral gunstig is voor mobiele verbindingen en verbindingen met een lage bandbreedte.
3. SSH-sleutelverificatie: Ed25519 is momenteel het voorkeursalgoritme voor SSH-sleutels. Het biedt compacte publieke sleutels van 32 bytes, snelle bewerkingen en weerstand tegen timing-side-channel-aanvallen. Zie ons bericht hierover. SSH-sleutelbeheer voor implementatierichtlijnen.
4. Cryptovaluta en blockchain: ECDSA (voornamelijk secp256k1 voor Bitcoin en Ethereum) beveiligt sleutelparen van wallets en transactiehandtekeningen. De compacte sleutelgrootte is met name belangrijk voor de efficiëntie van de blockchain.
5. Beveiliging van IoT-apparaten: De kleine sleutelgroottes en de lage rekenbelasting van ECC maken het de praktische keuze voor IoT-sensoren, slimme meters en embedded systemen met beperkte verwerkingskracht en batterijduur.
6. Sleuteluitwisseling voor versleutelde communicatie: ECDH en ECDHE worden gebruikt in berichtenapplicaties (Signal Protocol gebruikt X25519), e-mailversleuteling en VPN-protocollen om gedeelde sessiesleutels tot stand te brengen zonder geheimen te verzenden.

Implementatievoorbeeld: ECC in een productieomgeving met TLS en codeondertekening.

Een softwarebedrijf implementeert ECC in zijn TLS-certificaatinfrastructuur en codeondertekeningspipeline:

1. TLS-certificaatmigratie: De bestaande RSA-2048 TLS-certificaten op publiek toegankelijke webservers worden vervangen door ECDSA P-256-certificaten. De certificaatgrootte neemt af van ongeveer 1,200 bytes naar 400 bytes, waardoor het aantal uitgewisselde TLS-handshakebytes wordt verminderd en de verbindingstijd op mobiele netwerken wordt verkort.
2. TLS-serverconfiguratie: De servers zijn geconfigureerd om TLS 1.3 te ondersteunen met ECDHE X25519 als de voorkeurssleuteluitwisseling. Forward secrecy is nu verplicht voor alle verbindingen; eerdere sessies kunnen niet worden gedecodeerd, zelfs niet als de ECDSA-privésleutel later wordt gecompromitteerd.
3. Codeondertekeningspipeline: CodeSign Secure Alle software-releases worden ondertekend met behulp van ECDSA P-256. De ondertekeningssleutels worden opgeslagen in FIPS 140-3 gevalideerde bestanden. HSM'sDit zorgt ervoor dat de privésleutel nooit in het applicatiegeheugen terechtkomt. De grootte van de ECDSA-handtekening is ongeveer 64 bytes, vergeleken met 384 bytes voor RSA-3072, waardoor de overhead van de ondertekende artefacten wordt verminderd.
4. Interne serviceauthenticatie: Service-to-service communicatie maakt gebruik van wederzijdse TLS (mTLS) met ECDSA P-256-certificaten uitgegeven door een interne CA. Korte certificaatlevensduur (90 dagen, beheerd door CertSecure Manager) Beperk de blootstellingsperiode als een certificaat is gecompromitteerd.
5. PQC-migratieplanning: het bedrijf gebruikt CBOM Secure Een inventarisatie uitvoeren van alle geïmplementeerde ECC-instanties. Langdurige CA-privésleutels en infrastructuur voor codeondertekening worden aangemerkt als de eerste kandidaten voor migratie naar ML-DSA (FIPS 204) vóór de NIST-termijn van 2030 voor uitfasering.

Kernmanagement voor ECC

• Opslag van privésleutels: ECC-privésleutels moeten worden opgeslagen in FIPS 140-2 Level 2 of hoger gecertificeerde HSM-hardware voor CA-sleutels, codeondertekeningssleutels en andere langlevende, belangrijke sleutels. HSM's zorgen ervoor dat cryptografische bewerkingen plaatsvinden in fraudebestendige hardware; de ​​privésleutel komt nooit in het applicatiegeheugen van een server terecht die gecompromitteerd zou kunnen worden.
• Nonce (k-waarde) genereren in ECDSA: ECDSA-ondertekening vereist een unieke, willekeurige nonce k voor elke handtekening. Als k wordt hergebruikt in twee handtekeningen met dezelfde privésleutel, kan de privésleutel algebraïsch worden berekend uit de twee handtekeningen. Deze kwetsbaarheid werd misbruikt bij grootschalige aanvallen op hardwareapparaten. Gebruik deterministische ECDSA (RFC 6979) of door hardware gegenereerde nonces om dit risico te elimineren.
• Automatisering van de certificaatlevenscyclus: Nu het CA/Browser Forum de geldigheidsduur van TLS-certificaten tegen 2029 beperkt tot slechts 47 dagen, is handmatig certificaatbeheer op grote schaal niet haalbaar. Geautomatiseerd beheer van de certificaatlevenscyclus is vereist voor alle ECC TLS-certificaten. Zie CertSecure Manager voor geautomatiseerde detectie, verlenging en handhaving van beleid.

CodeSign Secure van Encryption Consulting

CodeSign Secure helpt softwareorganisaties vertrouwen op te bouwen bij eindgebruikers door de authenticiteit en integriteit van softwarereleases te waarborgen met behulp van ECC. CodeSign Secure gebruikt specifiek ECDSA met sleuteltypen zoals P-256 en P-384 om digitale handtekeningen te creëren die verifiëren dat software niet is gewijzigd sinds de ondertekening. Belangrijke functionaliteiten relevant voor ECC-implementatie:

• Sleutelopslag met HSM-ondersteuning: Ondertekeningsprivésleutels worden opgeslagen in FIPS 140-3 gevalideerde HSM's (die de PKCS#11- en FIPS 140-3-standaarden ondersteunen), waardoor wordt gegarandeerd dat ECC-privésleutels nooit de fraudebestendige hardware verlaten.
• Integratie van CI/CD-pijplijn: Automatiseert ondertekeningsworkflows binnen Jenkins, Azure DevOps, GitHub Actions en andere platforms, waardoor handmatige ondertekeningsstappen die menselijke fouten en vertragingen met zich meebrengen, worden geëlimineerd.
• Auditspoor en nalevingsrapportage: Gedetailleerde registratie van elke ondertekeningshandeling ondersteunt de nalevingsvereisten en levert bewijsmateriaal voor audits van het codeondertekeningsbeleid.
• Algoritmebeheer: Dit zorgt ervoor dat alleen goedgekeurde ECC-curven en hash-algoritmen worden gebruikt voor ondertekening, waardoor ontwikkelaars niet automatisch voor zwakke parameters kiezen.

Beperkingen van ECC

• Niet kwantumveilig: Het algoritme van Shor breekt ECDLP op een kwantumcomputer. Dit is de belangrijkste beperking voor een infrastructuur die lang meegaat. NIST stelt voor om ECC na 2030 uit te faseren, conform NIST IR 8547. Begin nu met de planning voor de PQC-migratie voor certificaathiërarchieën en codeondertekeningssleutels.
• De keuze van de curve is van cruciaal belang: De beveiliging is afhankelijk van de wiskundige eigenschappen van de gekozen curve. Gebruik uitsluitend gestandaardiseerde curves: NIST P-256, P-384, P-521, X25519 of Ed25519. Implementeer geen eigen curves of parameters.
• ECDSA-nonce-beveiligingsvereiste: Deterministische ECDSA (RFC 6979) moet worden gebruikt om het risico van hergebruik van de nonce te elimineren, wat de privésleutel zou blootleggen. Dit is een bekend implementatieprobleem dat in de praktijk al tot problemen heeft geleid.
• Beperkingen op het gebied van compatibiliteit met oudere systemen: Sommige oudere systemen, embedded devices en enterprise middleware ondersteunen geen ECC. Omgevingen die maximale compatibiliteit met legacy-systemen vereisen, hebben mogelijk nog steeds RSA nodig gedurende een overgangsperiode.

Conclusie

Elliptische-curve-cryptografie (ECC) is het geprefereerde asymmetrische cryptografische algoritme voor de meeste nieuwe implementaties vanwege de combinatie van sterke beveiliging, kleine sleutelgroottes, snelle bewerkingen en lage resourcevereisten. ECDSA P-256 en Ed25519 zijn de door NIST aanbevolen keuzes voor digitale handtekeningen en TLS; ECDHE verzorgt de verplichte forward-secret-sleuteluitwisseling in TLS 1.3. ECC is ingebed in TLS 1.3, FIDO2, SSH, S/MIME, codeondertekening en de meeste moderne beveiligingsprotocollen.

De cruciale kanttekening: ECC is niet kwantumveilig. Het algoritme van Shor doorbreekt ECDLP. Voor infrastructuren met een sleutellevensduur van meerdere jaren, waaronder privésleutels van certificeringsinstanties, infrastructuur voor codeondertekening en langlopende TLS-hiërarchieën, moeten organisaties nu al beginnen met de planning voor de migratie naar PQC. NIST heeft ML-KEM (FIPS 203) en ML-DSA (FIPS 204) gestandaardiseerd als de post-kwantumvervangingen. Zie voor meer informatie onze artikelen over symmetrische versus asymmetrische encryptie en de vergelijking van encryptiealgoritmen.

Veelgestelde Vragen / FAQ

Wat is Elliptic Curve Cryptography (ECC)?

ECC is een cryptografisch systeem met publieke sleutels, gebaseerd op elliptische krommen over eindige velden, gedefinieerd door y² = x³ + ax + b. De beveiliging ervan berust op het ECDLP (Elliptic Curve Discrete Logarithm Problem), dat geen bekende sub-exponentiële oplossing heeft op goed gekozen krommen. Een 256-bits ECC-sleutel biedt een beveiliging van ongeveer 128 bits, equivalent aan RSA-3072. Het systeem werd in 1985 voorgesteld door Neal Koblitz en Victor S. Miller.

Wat is het verschil tussen ECDH en ECDSA?

ECDH (Elliptic Curve Diffie-Hellman) is een sleuteluitwisselingsprotocol dat een gedeeld geheim tussen twee partijen vaststelt zonder dit te verzenden. ECDHE (ephemeral) biedt forward secrecy; TLS 1.3 vereist dit voor alle verbindingen. ECDSA (Elliptic Curve Digital Signature Algorithm) is een handtekeningalgoritme dat privésleutels gebruikt om gegevens te ondertekenen en publieke sleutels om handtekeningen te verifiëren. Het wordt gebruikt in TLS-certificaten, codeondertekening en SSH-authenticatie.

Hoe verhoudt ECC zich tot RSA?

ECC P-256 biedt 128-bits beveiliging met een sleutel van 32 bytes; RSA heeft 3072 bits nodig voor een vergelijkbare beveiliging. ECDSA-ondertekening is sneller dan RSA-ondertekening bij een vergelijkbaar beveiligingsniveau. ECC-certificaten zijn ongeveer een derde zo groot als RSA-certificaten. Geen van beide is kwantumveilig; beide vereisen migratie naar post-kwantumalgoritmen (ML-KEM, ML-DSA).

Welke ECC-curven worden door NIST aanbevolen?

NIST FIPS 186-5 specificeert: P-256 (128-bits beveiliging, meest gebruikt), P-384 (192-bits, Secret-niveau), P-521 (256-bits, Top Secret). X25519 en Ed25519 zijn breed ondersteunde en goedgekeurde alternatieven: X25519 voor TLS 1.3-sleuteluitwisseling; Ed25519 als het voorkeursalgoritme voor SSH-sleutels.

Is ECC kwantumveilig?

Nee. Het algoritme van Shor op een kwantumcomputer lost ECDLP efficiënt op en kraakt daarmee alle op ECC gebaseerde cryptografie. NIST heeft standaardisaties ontwikkeld voor post-kwantumvervangingen: ML-KEM (FIPS 203) voor sleuteluitwisseling en ML-DSA (FIPS 204) voor handtekeningen. NIST IR 8547 stelt voor om ECC na 2030 af te schaffen en na 2035 niet meer toe te staan ​​in nieuwe toepassingen.

Wanneer moet ECC in plaats van RSA worden gebruikt?

Voor alle nieuwe implementaties zonder bestaande beperkingen: TLS-certificaten (ECDSA P-256), SSH-sleutels (Ed25519), codeondertekening (ECDSA P-256 of P-384), DNSSEC, mobiele apparaten en IoT. Gebruik RSA alleen wanneer ECC niet wordt ondersteund door bestaande systemen of wanneer specifieke compliance-vereisten dit vereisen.