Hoe encryptiesleutels werken: de basis van bestandsbeveiliging
Begrijp in eenvoudige termen hoe encryptiesleutels werken. Leer over sleutelgeneratie, uitwisseling en beheer.
Een versleutelingssleutel is een reeks willekeurige bits die gegevens vergrendelt en ontgrendelt. Voor moderne bestandsoverdracht betekent dat doorgaans een 256-bits AES-sleutel — 32 bytes willekeurige gegevens gegenereerd door een cryptografisch veilige willekeurige numbergenerator (CSPRNG). Hetzelfde algoritme dat een video van 10 GB in versleutelde tekst omzet, kan die alleen unscramble als het precies dezelfde sleutel krijgt. Sleutelbeveiliging is waar encryptie slaagt of faalt: een perfect AES-256-cipher is waardeloos als de sleutel zwak, voorspelbaar of blootgesteld is. Dit artikel doorloopt hoe sleutels worden gemaakt, gedeeld, opgeslagen en vernietigd in echte diensten zoals HexaTransfer, Tresorit en Proton Drive.
Sleutels zijn gewoon willekeurige getallen
Een 256-bits sleutel is 32 bytes. Als je er één in de browser genereert, ziet het er zo uit:
const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]
Wat het een "sleutel" maakt is hoe een algoritme het gebruikt. AES-256-GCM neemt een 256-bits sleutel, breidt die uit via een sleutelrooster tot 15 rondsleutels en gebruikt die om 128-bits blokken te scramble over 14 ronden. De wiskunde maakt niet uit waar de bits vandaan komen — het vereist alleen dat ze geheim en onvoorspelbaar zijn.
"Onvoorspelbaar" is de moeilijkere helft. Als een aanvaller de toestand van je RNG kan raden, kunnen ze je sleutel opnieuw genereren. De Debian OpenSSL-bug van 2006 reduceerde sleutelentropie tot 15 bits voor twee jaar voordat die werd ontdekt — een schoolboekvoorbeeld van wat er gebeurt als willekeurigheid faalt.
Cryptografisch veilige willekeurigheid
Browsers bieden crypto.getRandomValues() die uit de CSPRNG van het besturingssysteem puurt: /dev/urandom op Linux, BCryptGenRandom op Windows, SecRandomCopyBytes op macOS. Deze mixen op hun beurt meerdere entropiebronnen — interrupt-timings, schijfzoekopdrachttijden, hardware-RNG-chips zoals Intel's RDRAND.
Gebruik Math.random() niet voor sleutels. Het is een voorspelbare Mersenne Twister en de toestand kan vaak worden hersteld uit een paar uitvoerwaarden.
Serverside zijn crypto.randomBytes() in Node.js en secrets.token_bytes() in Python wikkels om de OS-CSPRNG en zijn veilig. De NIST SP 800-90A en SP 800-90B-standaarden definiëren CSPRNG-vereisten; Linux kernel 5.17+ gebruikt een BLAKE2s-gebaseerd ontwerp dat eraan voldoet.
Symmetrische sleutels: één sleutel, twee richtingen
Symmetrische algoritmen zoals AES gebruiken één sleutel voor zowel versleuteling als ontsleuteling. De sleutelgrootteopties:
- 128-bits — 2^128 mogelijke waarden, veilig voor de meeste doeleinden, goedgekeurd voor SECRET door NSA CNSSP-15.
- 192-bits — zeldzaam, gebruikt in sommige overheidscontexten.
- 256-bits — 2^256 waarden, goedgekeurd voor TOP SECRET, huidige standaard voor bestandsoverdrachtsservices.
Het verdubbelen van de sleutelgrootte verdubbelt de brute-forcemoeilijkheid niet — het kwadrateert die. 2^128 is al buiten bereik (de leeftijd van het universum maal 10 miljard met alle computers op aarde). 256-bits is een afdekking tegen kwantumcomputers, waar Grover's algoritme de symmetrische sleutelsterkte effectief halveert.
Het harde probleem met symmetrische sleutels: dezelfde sleutel naar beide partijen krijgen zonder dat iemand die onderschept.
Asymmetrische sleutels: de parenstruc
Publieke-sleutelcryptografie lost sleuteldistributie op. Elke partij genereert een wiskundig gekoppeld sleutelpaar: een publieke sleutel (openlijk gedeeld) en een privésleutel (geheim gehouden). Alles versleuteld met de publieke sleutel kan alleen worden ontsleuteld met de privésleutel.
Veelvoorkomende asymmetrische sleuteltypen:
- RSA-2048 — 2048-bits modulus, breed ondersteund, langzaam. Gebruikt in TLS-certificaten.
- RSA-4096 — sterker, zelfs langzamer.
- Curve25519 (X25519) — 256-bits elliptische curvesleutel, snel, gebruikt door Signal en WireGuard.
- Ed25519 — 256-bits ondertekeningssleutel, gebruikt door SSH en Git-commit-ondertekening.
De privésleutel alleen is 32–512 bytes afhankelijk van het algoritme. RSA-privésleutels zijn groter omdat ze meerdere priemgetallen bevatten; Curve25519-privésleutels zijn slechts 32 willekeurige bytes.
Hybride: combineer de twee voor echte systemen
Geen enkel praktisch systeem versleutelt grote bestanden direct met RSA. Elk echt protocol — TLS, PGP, Age, Signal, elke serieuze bestandsoverdrachtsservice — gebruikt in plaats daarvan hybride versleuteling:
- Genereer een willekeurige 256-bits AES-sleutel ("sessiesleutel" of "bestandssleutel").
- Versleutel het bestand met AES-256-GCM.
- Versleutel de sessiesleutel met de publieke sleutel van de ontvanger.
- Stuur beide.
De ontvanger ontsleutelt de sessiesleutel met zijn privésleutel en gebruikt die vervolgens om het bestand te ontsleutelen. Je krijgt de snelheid van symmetrische versleuteling en het gemak van sleuteldistributie van asymmetrisch.
Voor browsergebaseerde bestandsoverdracht wordt de "publieke sleutel" vaak vervangen door het URL-fragment: de verzender genereert een sessiesleutel, embed die in de URL na #, en de browser van de ontvanger leest die lokaal. Eenvoudiger, en werkt zonder dat ontvangers een sleutelpaar hoeven te hebben.
Sleutels afleiden van wachtwoorden
Gebruikers typen wachtwoorden; algoritmen willen uniforme willekeurige bits. Een sleutelafleidingsfunctie (KDF) overbrugt ze:
- PBKDF2-HMAC-SHA-256 — itereert een hashfunctie. OWASP 2023 beveelt 600.000 iteraties aan. Beschikbaar in Web Crypto API.
- scrypt — geheugenmoeilijk, weerstaat GPU-aanvallen. Parameters:
N=2^17, r=8, p=1. - Argon2id — huidige beste praktijk, winnaar van de Password Hashing Competition 2015. Parameters:
memory=64 MB, iterations=3, parallelism=4.
Een KDF voegt een salt toe (willekeurig, opgeslagen naast de versleutelde tekst) en een werkfactor (iteraties) om brute force te vertragen. Een willekeurig wachtwoord van 12 tekens door Argon2id met 64 MB geheugen kost een GPU-farm duizenden jaren om te doorzoeken. Een zwak wachtwoord zoals zomer2024 valt in seconden ongeacht de KDF — de KDF kan geen entropie toevoegen die er niet was.
Sleutelopslag: waar leven sleutels?
Sleutels moeten ergens bestaan, en dat ergens is een beveiligingskritische beslissing:
- Browsergeheugen (alleen sessie). De standaard voor efemere bestandsoverdrachten. Sleutel wordt gegenereerd, gebruikt en weggegooid binnen de paginabezoek.
- URL-fragment. Gedeeld via de link, opgeslagen in de browsergeschiedenis van de ontvanger. Beperkte levensduur is van belang.
- Lokale opslag / IndexedDB. Persistent maar toegankelijk voor elke JavaScript op de oorsprong. Riskant tenzij versleuteld met een andere sleutel.
- OS-sleutelhanger — macOS Sleutelhanger, Windows DPAPI, Linux libsecret. Hardwareondersteund op sommige platformen.
- Hardware Security Module (HSM) — YubiKey, cloud HSM (AWS CloudHSM, Azure Dedicated HSM). Sleutels verlaten de hardware nooit.
- Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Gecentraliseerd, auditeerbaar, geprijsd rond €1/sleutel/maand.
Voor zero-knowledge bestandsoverdracht leeft de sleutel in het URL-fragment en de browser van de verzender. De server slaat die nooit op.
Sleutelrotatie en -vernietiging
Langlevende sleutels accumuleren risico. Beste praktijk is rotatie:
- TLS-certificaten: 90-daagse rotatie (Let's Encrypt standaard), 398-dag maximum voor publieke CA's vanaf 2020.
- Gegevensversleutelingssleutels: doorgaans elke 90 dagen tot 1 jaar geroteerd in conforme systemen (PCI DSS 4.0 Vereiste 3.6).
- Hoofdsleutels: jaarlijks geroteerd of bij personeelswisselingen.
Vernietiging is ook van belang. Gewoon sleutelbestanden van schijf verwijderen is onvoldoende — SSD's kunnen gegevens bewaren in slijtage-egalisatiegebieden. Veilige vernietiging vereist overschrijven of toegewijde HSM-verwijderopdrachten. Cryptografische verwijdering — de sleutel weggooien zodat de versleutelde gegevens permanent onleesbaar worden — is vaak de schoonste aanpak voor bulkgegevens.
Bestandsoverdrachtsservices gebruiken doorgaans per-bestandssleutels die alleen bestaan voor de levensduur van de overdracht (24 uur tot 7 dagen) en worden weggegooid samen met de versleutelde tekst bij het verlopen.
Zwakke sleutelpraktijken herkennen
Drie veelvoorkomende faalpatronen om op te letten:
- Hardcoded sleutels in clientcode. Als de sleutel voor elke gebruiker hetzelfde is, is het geen sleutel — het is verduistering.
- Sleutels opgeslagen naast versleutelde tekst op dezelfde server of database. Een inbreuk stelt beide bloot.
- Geen sleutelrotatie. Verouderde systemen met tien jaar oude versleutelingssleutels hebben ruwweg een decennium aan geaccumuleerd inbreukrisico.
Een gerenommeerde dienst publiceert een cryptografisch witboek over sleutelgeneratie, -opslag, -rotatie en -vernietiging — en onderwerpt zich aan audits door derden van bedrijven als Cure53 of Trail of Bits.
Perspectief
Voor gevoelig bestandsdelen: kies een dienst die 256-bits sleutels client-side genereert via crypto.getRandomValues(), die alleen in het URL-fragment insluit (nooit naar de server verzonden), wachtwoordafgeleide sleutels ondersteunt via PBKDF2 of Argon2id en zowel de sleutel als de versleutelde tekst automatisch binnen 24 uur laat verlopen.
Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.
Verstuur grote bestanden veilig met end-to-end-versleuteling
Draag bestanden tot 10 GB gratis over met end-to-end-versleuteling. Geen account nodig. Uw bestanden worden in uw browser versleuteld voordat ze worden geüpload — niemand anders kan ze lezen.
Een bestand verzenden