Meteen naar de inhoud

Certificaten voor 47 dagen komen eraan. Ben je er klaar voor?

Handel nu →

Beveilig de gegevens van uw organisatie met deze encryptie-algoritmen

Gegevensbeveiliging is een van de essentiële onderdelen van een organisatie en kan op verschillende manieren worden bereikt. Encryptiesleutels spelen een belangrijke rol in het gehele gegevensverwerkingsproces. Gegevensversleuteling zet de platte tekst om in een gecodeerde vorm (onleesbaar), zodat alleen geautoriseerde personen/partijen er toegang toe hebben.

De keuze van het encryptiealgoritme bepaalt de sterkte van uw gegevensbescherming: een verkeerde keuze kan gegevens kwetsbaar maken voor brute-force-aanvallen, bekende cryptanalytische zwakheden of toekomstige bedreigingen door kwantumcomputers. Gegevensversleuteling zet platte tekst om in versleutelde tekst die alleen door geautoriseerde partijen met de juiste sleutel kan worden gelezen. De aanbevolen aanpak: gebruik AES-256-GCM voor data in rust, TLS 1.3 met ECDHE voor data in transit, ECC P-256 of RSA-3072 voor asymmetrische bewerkingen en vermijd DES en 3DES bij alle nieuwe implementaties. Sleutelbeheer, en niet het algoritme zelf, is het meest voorkomende faalpunt bij encryptie-implementaties.

Kort antwoord: Welk encryptiealgoritme moet uw organisatie gebruiken?

Het algoritme is afhankelijk van het gebruiksscenario voor gegevensbescherming. Voor data in rust gebruikt u AES-256-GCM: snel, aanbevolen door NIST en biedt geauthenticeerde encryptie die naast encryptie ook manipulatie detecteert. Voor data in transit gebruikt u TLS 1.3 met AES-256-GCM of ChaCha20-Poly1305 cipher suites en ECDHE-sleuteluitwisseling voor forward secrecy. Voor digitale handtekeningen en certificaten gebruikt u ECDSA P-256 (voorkeur voor nieuwe implementaties vanwege de kleinere sleutelgrootte en snellere bewerkingen) of RSA-3072 (minimum; RSA-2048 is het absolute minimum en wordt voorgesteld om na 2030 te worden uitgefaseerd volgens NIST IR 8547). Vermijd DES (56-bits sleutel, gekraakt), 3DES (formeel afgekeurd door NIST voor nieuwe toepassingen in 2019, Sweet32-kwetsbaarheid), RC4 en MD5. Voor de periode na de kwantumcomputers is het raadzaam om de migratie van asymmetrische algoritmen naar ML-KEM (FIPS 203) en ML-DSA (FIPS 204) te plannen.

Vergelijking van encryptiealgoritmen

De onderstaande tabel vergelijkt de meest voorkomende encryptiealgoritmen op basis van de dimensies die van belang zijn voor besluitvorming op het gebied van beveiliging. Deze blog richt zich specifiek op operationele selectierichtlijnen: welk algoritme voor welk gebruiksscenario, en waarom, met een expliciete vermelding van de NIST-conformiteitsstatus voor elk algoritme.

AlgoritmeTypeSleutelmaatBeveiligingskrachtSnelheidNIST-statusGebruik voor
AES-128-GCMSymmetrische blokversleuteling (AEAD)128 beetjes128-bit (post-kwantum: ~64-bit)Zeer snel (hardwareversneld)Goedgekeurd; FIPS 197Gegevens in rust, TLS-sessieversleuteling
AES-256-GCMSymmetrische blokversleuteling (AEAD)256 beetjes256-bit (post-kwantum: ~128-bit)Snel (hardwareversneld)Goedgekeurd; FIPS 197; CNSA 2.0 vereist voor nationale veiligheidGegevens in rust, gegevens onderweg, gegevens met de hoogste gevoeligheid
ChaCha20-Poly1305Symmetrische stroomversleuteling (AEAD)256 beetjes256-bitZeer snel (geen hardwareversnelling nodig)Goedgekeurd; gebruikt in TLS 1.3TLS-sessieversleuteling; mobiele apparaten en IoT-apparaten waar AES-NI niet beschikbaar is.
RSA-2048Asymmetrisch (publieke sleutel)2048-bits modulus112-bitLangzaam voor ondertekening; snel voor verificatie.Goedgekeurd tot en met 2030; voorgesteld als afgeschreven na 2030 volgens NIST IR 8547TLS-certificaten, sleuteluitwisseling (verouderd); codeondertekening (minimum)
RSA-3072Asymmetrisch (publieke sleutel)3072-bits modulus128-bitLangzamer dan RSA-2048Goedgekeurd; aanbevolen voor nieuwe RSA-implementaties.Nieuwe RSA-gebaseerde certificaat- en handtekeninginfrastructuur
ECDSA P-256Asymmetrisch (elliptische curve)256-bits punt128-bitSnelGoedgekeurd; FIPS 186-5TLS-certificaten, codeondertekening, digitale handtekeningen (voorkeur boven RSA-3072 voor nieuwe implementaties)
3DES (drievoudige DES)Symmetrische blokcijfer168-bits nominaal (112-bits effectief)Effectief 112-bits (Sweet32-aanval op een blokgrootte van 64 bits)LangzaamNiet langer geschikt voor nieuwe toepassingen (NIST SP 800-131A Rev. 2, 2019)Alleen voor verificatie van oudere systemen; niet gebruiken voor nieuwe versleuteling.
DESSymmetrische blokcijfer56 beetjesMinder dan 56 bits (uitputtende sleutelzoekactie mogelijk)LangzaamNiet goedgekeurd; niet toegestaanGebruik geen

Prestatie: Wat telt in de praktijk?

De prestaties van een algoritme zijn relevant, maar vormen zelden de belangrijkste beslissingsfactor voor de meeste organisaties. Moderne processors met AES-NI (AES Native Instructions) hardwareversnelling voeren AES-256-GCM snel genoeg uit, waardoor de prestaties van het algoritme doorgaans geen knelpunt vormen voor dataversleuteling in rust of tijdens transport, zelfs bij een hoge doorvoer. De prestatieaspecten die er in de praktijk wel toe doen, zijn:

Vergelijkingsgrafiek van de prestaties van encryptiealgoritmen, met de doorvoersnelheid van AES, 3DES en andere symmetrische algoritmen.
  • Symmetrische encryptie (AES-256-GCM versus ChaCha20-Poly1305): Op hardware met AES-NI is AES-256-GCM doorgaans sneller. Op mobiele of IoT-hardware zonder AES-NI is ChaCha20-Poly1305 aanzienlijk sneller. TLS 1.3 ondersteunt beide en onderhandelt op basis van de mogelijkheden van de client en de server.
  • Asymmetrische bewerkingen (RSA versus ECC): RSA-verificatie (bewerking met openbare sleutel) is snel; RSA-ondertekening (bewerking met privésleutel) is traag. ECDSA P-256-ondertekening is aanzienlijk sneller dan RSA-3072-ondertekening bij een gelijkwaardig beveiligingsniveau, wat van belang is voor codeondertekening met hoge doorvoer of certificaatuitgifte. ECDSA-verificatie is iets trager dan RSA-verificatie.
  • De belangrijkste factoren die de grootte van een apparaat beïnvloeden zijn opslag en bandbreedte: Een RSA-3072-certificaat is ongeveer zes keer groter dan een ECDSA P-256-certificaat met een gelijkwaardige beveiliging. Voor DNSSEC (waarbij antwoorden in UDP-pakketten moeten passen) en mobiele applicaties (waar bandbreedte en latentie belangrijk zijn) verlagen ECC-sleutelgroottes de overhead aanzienlijk.

AES: De standaard voor symmetrische encryptie

AES (Advanced Encryption Standard) werd in 2001 door NIST geselecteerd na een openbare wedstrijd en is gedefinieerd in FIPS 197. Het is de universeel geaccepteerde standaard voor symmetrische encryptie in de overheid, financiële dienstverlening, gezondheidszorg en de meeste andere sectoren. AES is een blokcijfer dat blokken van 128 bits verwerkt met behulp van substitutie-permutatiebewerkingen die in rondes worden toegepast:

Diagram van het symmetrische encryptie- en decryptieproces, met de stappen voor platte tekst, encryptiesleutel, versleutelde tekst en decryptie.
Coderings- en decoderingsproces
SleutelmaatRondenBeveiligingskrachtGebruik geval
128 beetjes10128-bit (~64-bit na quantum met Grover's)Standaard gegevensversleuteling; TLS-sessiesleutels
192 beetjes12192-bitGeclassificeerde informatie op het niveau "Geheim" (Amerikaanse overheid)
256 beetjes14256-bit (~128-bit na quantum met Grover's)Gegevens met de hoogste gevoeligheid; CNSA 2.0-vereiste; standaardaanbeveling voor nieuwe implementaties

Het AES-versleutelingsproces bestaat uit vier bewerkingen die in elke ronde worden toegepast: SubBytes (niet-lineaire bytevervanging met behulp van de S-box), ShiftRows (cyclische byteverschuiving binnen rijen van de 4×4-toestandsmatrix), MixColumns (lineaire menging over kolommen voor diffusie) en AddRoundKey (XOR met de rondesleutel die is afgeleid van de versleutelingssleutel). In de laatste ronde wordt MixColumns weggelaten. Bij decryptie wordt de inverse van elke bewerking in omgekeerde volgorde toegepast.

Diagram van de AES-versleutelingsfasen, waarin de transformatie van platte tekst naar versleutelde tekst wordt weergegeven via de bewerkingen SubBytes, ShiftRows, MixColumns en AddRoundKey.
AES-versleutelingsfasen: van platte tekst naar versleutelde tekst

Op maat gemaakte encryptiediensten

Wij beoordelen, ontwikkelen strategieën en implementeren encryptiestrategieën en -oplossingen.

Algoritmekeuze: welk algoritme te gebruiken voor welk gebruiksscenario?

Gebruik gevalAanbevolen algoritmevermijdenReferentie
Gegevens in rust (databases, bestandssystemen, back-ups)AES-256-GCMDES, 3DES, AES-ECB (geen integriteit), AES-CBC zonder MACNIST SP 800-111; FIPS 197
Gegevens in transit (TLS)TLS 1.3 met AES-256-GCM of ChaCha20-Poly1305; ECDHE-sleuteluitwisselingSSL 3.0, TLS 1.0/1.1, RC4, 3DES-coderingssuitesNIST SP 800-52 Rev. 2
Digitale handtekeningen en certificatenECDSA P-256 (voorkeur) of RSA-3072 (minimum voor nieuwe RSA); RSASSA-PSS voor RSARSA-1024, RSA-2048 voor nieuwe, duurzame infrastructuur, DSANIST FIPS 186-5; NIST IR 8547
Sleuteluitwisseling / inkapselingECDH P-256 of X25519; post-quantum: ML-KEM (FIPS 203)RSA-sleuteluitwisseling (geen forward secrecy); statische DHNIST SP 800-56A Rev. 3; FIPS 203
Hashing (integriteit, handtekeningen)SHA-256 of SHA-384MD5, SHA-1 (beide niet bestand tegen botsingen)NIST FIPS 180-4; NIST SP 800-131A
Mobiel en IoT (geen AES-NI-hardware)ChaCha20-Poly1305 voor encryptie; Ed25519 voor handtekeningenDES, RC4, zwakke cijfersuitesRFC 8439 (ChaCha20-Poly1305); RFC 8032 (Ed25519)
Post-kwantummigratie (asymmetrisch)ML-KEM (FIPS 203) voor sleuteluitwisseling; ML-DSA (FIPS 204) voor handtekeningen.RSA en ECC alleen voor nieuwe, duurzame infrastructuurNIST-FIPS 203, 204, 205; NISTIR 8547

Implementatievoorbeeld: Meerlaagse encryptie in een financiële dienstverleningsomgeving

Een financiële dienstverlener die klantgegevens en transactiedata versleutelt, implementeert de volgende algoritme-reeks:

  1. Gegevens in rust (encryptie van databasevelden): AES-256-GCM met per-record encryptiesleutels (DEK's). Elke DEK is gekoppeld aan een sleutelversleutelingssleutel (KEK) die is opgeslagen in een HSM. De HSM voert de sleutelontsleuteling intern uit; de KEK komt nooit in het applicatiegeheugen terecht.
  2. Gegevens in rust (volledige databaseversleuteling): AES-256-CBC met HMAC-SHA-256 (voor compatibiliteit met de native encryptiefunctie van de database, die geen GCM ondersteunt). Veldniveau AES-256-GCM wordt gebruikt voor de meest gevoelige velden (rekeningnummers, BSN's) waar per record integriteitscontrole vereist is.
  3. Gegevens in transit (publiekelijk toegankelijke webapplicaties): TLS 1.3 maakt gebruik van de AES-256-GCM-coderingssuite. De ECDHE P-256-sleuteluitwisseling zorgt voor forward secrecy. TLS-certificaten gebruiken ECDSA P-256, waardoor de certificaatgrootte en de TLS-handshaketijd kleiner zijn dan bij RSA-2048-certificaten.
  4. Gegevens in transit (interne API's voor communicatie tussen diensten): Wederzijdse TLS (mTLS) met dezelfde TLS 1.3-configuratie. Zowel de client als de server beschikken over ECDSA P-256-certificaten, waarmee cryptografische authenticatie van beide zijden van de verbinding wordt geboden.
  5. Codeondertekening voor software-releases: RSASSA-PSS met SHA-256 en RSA-3072, ondertekening uitgevoerd binnen een HSM met behulp van CodeSign SecureDe ondertekeningssleutel verlaat de HSM nooit.
  6. PQC-planning: de cryptografische inventaris van de organisatie (geproduceerd met behulp van CBOM Secure) identificeert alle RSA- en ECC-instanties. Een gefaseerd migratieplan geeft prioriteit aan langlopende certificaathiërarchieën en infrastructuur voor codeondertekening voor migratie naar ML-DSA (FIPS 204) tegen 2027.

Sleutelbeheer: De werkelijke bepalende factor voor de effectiviteit van encryptie

De sterkte van een encryptiealgoritme betekent niets als de sleutels gecompromitteerd zijn. Een organisatie die AES-256-GCM gebruikt met een sleutel die is opgeslagen in een configuratiebestand in platte tekst op dezelfde server als de versleutelde gegevens, heeft in de praktijk ongeveer dezelfde bescherming als wanneer er geen encryptie wordt gebruikt: elke aanvaller die de versleutelde gegevens leest, kan ook de sleutel lezen. Aanbevolen werkwijzen voor sleutelbeheer bij de encryptie van organisatiegegevens:

  • Scheid de sleutels van de versleutelde gegevens: Versleutelingssleutels mogen niet op dezelfde locatie worden opgeslagen als de gegevens die ze beschermen. Gebruik een speciale sleutelbeheerservice (KMS) of hardwarebeveiligingsmodule (HSM) om versleutelingssleutels op te slaan en te beheren. Zie HSM als een service voor hardwarematige sleutelopslag.
  • Gebruik envelopversleuteling: Individuele records of bestanden worden versleuteld met een Data Encryption Key (DEK), en de DEK wordt vervolgens versleuteld met een Key Encryption Key (KEK) die is opgeslagen in het KMS/HSM. Dit ontkoppelt sleutelrotatie van dataherversleuteling: het roteren van de KEK is operationeel veel eenvoudiger dan het herversleutelen van grote datasets.
  • Definieer cryptoperioden en dwing sleutelrotatie af: NIST SP 800-57 definieert aanbevolen cryptoperiodes voor verschillende sleuteltypen. Symmetrische dataversleutelingssleutels: twee tot drie jaar, afhankelijk van het volume. RSA-privésleutels: één tot drie jaar. Rotatie vereist ofwel het opnieuw versleutelen van de gegevens met de nieuwe DEK, ofwel (bij envelopversleuteling) het opnieuw verpakken van de DEK met de nieuwe KEK.
  • Inventariseer alle cryptografische activa: Organisaties kunnen niet beschermen wat ze niet in kaart hebben gebracht. CBOM Secure Ontdekt alle encryptiesleutels, certificaten en algoritmen die in uw omgeving worden gebruikt, inclusief verborgen implementaties en verouderde algoritmen die mogelijk door individuele ontwikkelteams zonder centraal toezicht zijn geïmplementeerd.

Beperkingen en afwegingen

  • Sterkere algoritmes zijn niet altijd sneller: AES-256 heeft 14 rondes, tegenover 10 voor AES-128; de extra rondes zorgen voor extra rekenkracht. Op hardware met AES-NI is het verschil voor de meeste toepassingen verwaarloosbaar. Op hardware zonder AES-NI-acceleratie kan AES-256 30-40% trager zijn dan AES-128.
  • Asymmetrische algoritmen zijn niet geschikt voor massaversleuteling: RSA- en ECC-bewerkingen zijn vele malen trager dan AES voor het versleutelen van grote hoeveelheden data. Asymmetrische versleuteling wordt gebruikt voor kleine data-items (sleutels, handtekeningen, certificaten), terwijl symmetrische versleuteling bulkdata verwerkt. Het gebruik van RSA voor bulkversleuteling van grote bestanden leidt tot onpraktisch trage versleutelingssnelheden.
  • GCM-authenticatietaglimieten: AES-GCM gebruikt een 96-bits nonce (initialisatievector). Als de nonce wordt herhaald met dezelfde sleutel, wordt de GCM-authenticatie verbroken en kunnen zowel de vertrouwelijkheid als de integriteit van eerder versleutelde gegevens in gevaar komen. Nonce-beheer is cruciaal: nonces mogen nooit worden hergebruikt met dezelfde GCM-sleutel. Sleutelrotatie en nonce-tellers per sleutel bieden hiervoor een oplossing.
  • Algoritmeovergangen brengen operationele kosten met zich mee: Het migreren van het ene algoritme naar het andere vereist het opnieuw versleutelen van bestaande gegevens, het bijwerken van alle systemen die deze gegevens lezen en schrijven, en het vernieuwen van alle bijbehorende sleutels en certificaten. PQC-migratie voor organisaties met een grote RSA/ECC-infrastructuur is een meerjarig programma, geen eenmalige actie.

Conclusie

De keuze van het algoritme is het beginpunt van encryptie, niet het eindpunt. AES-256-GCM voor data in rust, TLS 1.3 met ECDHE voor data in transit en ECDSA P-256 of RSA-3072 voor digitale handtekeningen vormen de huidige basis voor nieuwe implementaties. De algoritmevergelijking in dit artikel biedt het kader voor die keuze; de ​​sleutelbeheerpraktijken die deze sleutels beschermen, bepalen of de encryptie daadwerkelijk de bescherming biedt die het zou moeten bieden. Organisaties die willen weten hoe hun huidige algoritme-implementatie ervoor staat en waar de hiaten zitten, moeten beginnen met een cryptografische inventarisatie. Wilt u advies over de selectie van encryptiealgoritmen, de architectuur van sleutelbeheer of de planning van PQC-migratie? Neem dan contact op met Encryption Consulting . Lees ook ons ​​artikel over symmetrische versus asymmetrische encryptie.

Veelgestelde Vragen / FAQ

Welk encryptiealgoritme moeten organisaties gebruiken voor data die niet in gebruik is?

AES-256-GCM is het aanbevolen algoritme. Het biedt een beveiliging van 256 bits, geauthenticeerde encryptie (detecteert manipulatie via de GCM-authenticatietag), ondersteuning voor hardwareversnelling en is goedgekeurd door NIST (FIPS 197) en vereist door CNSA 2.0 voor nationale veiligheidssystemen. AES-128-GCM is ook acceptabel voor minder gevoelige gegevens.

Wat is het verschil tussen symmetrische en asymmetrische encryptie?

Symmetrische encryptie gebruikt dezelfde sleutel voor zowel encryptie als decryptie (AES, ChaCha20) en is snel voor grote hoeveelheden data. Asymmetrische encryptie gebruikt een sleutelpaar (RSA, ECC) – een publieke sleutel voor encryptie en een privésleutel voor decryptie – en is trager, maar lost het probleem van sleuteldistributie op. In de praktijk worden ze samen gebruikt: asymmetrische encryptie genereert en wisselt op een veilige manier een symmetrische sessiesleutel uit voor bulkencryptie.

Is AES-256 kwantumveilig?

AES-256 behoudt een effectieve beveiliging van ongeveer 128 bits tegen Grovers kwantumalgoritme, wat NIST als voldoende beschouwt. AES-128 is kwetsbaarder (ongeveer 64 bits effectieve beveiliging na kwantumversleuteling). RSA en ECC zijn niet kwantumveilig: Shor's algoritme kan ze kraken. NIST heeft standaardisaties opgesteld voor vervanging van asymmetrische algoritmen na kwantumversleuteling (ML-KEM/FIPS 203, ML-DSA/FIPS 204).

Waarom wordt 3DES uitgefaseerd?

3DES heeft slechts een effectieve beveiliging van 112 bits (de meet-in-the-middle-aanval reduceert deze van de nominale sleutellengte van 168 bits), en de blokgrootte van 64 bits maakt het kwetsbaar voor de Sweet32-aanval op basis van de verjaardag van de ontvanger bij langdurige verbindingen. NIST heeft 3DES formeel afgekeurd voor nieuwe toepassingen in SP 800-131A Rev. 2 (2019). Gebruik in plaats daarvan AES.

Wanneer moet ECC in plaats van RSA worden gebruikt?

ECC P-256 biedt 128-bits beveiliging met een sleutel van 32 bytes, in tegenstelling tot de 384-byte sleutel van RSA-3072. ECC heeft de voorkeur voor TLS-certificaten (kleinere certificaatgrootte), codeondertekening (kleinere handtekeningen), mobiele apparaten en IoT (lagere rekenbelasting) en DNSSEC. Gebruik RSA wanneer compatibiliteit met oudere systemen dit vereist; anders is ECC de betere keuze voor nieuwe implementaties.

Wat is AES-GCM en waarom heeft het de voorkeur boven AES-CBC?

AES-GCM biedt geauthenticeerde encryptie: het versleutelt gegevens en voegt een GCM-authenticatietag toe die elke wijziging in de versleutelde tekst detecteert. AES-CBC biedt alleen vertrouwelijkheid, zonder integriteitscontrole. AES-CBC is bovendien kwetsbaar voor padding oracle-aanvallen wanneer het onjuist wordt geïmplementeerd. AES-GCM wordt aanbevolen volgens NIST SP 800-38D voor alle nieuwe implementaties van symmetrische encryptie.