Waarom een groter sleutelnummer een VPN niet veiliger maakt
Sleutelgrootte betekent iets binnen één algoritme en één rol. Verificatie van de tegenpartij, keuze van de suite, patches en registraties van de operator zijn vragen die het niet beantwoordt.
De advertentie zegt 256-bit, het andere product zegt 128-bit, en de conclusie lijkt voor de hand te liggen tot je opmerkt dat de getallen verschillende dingen beschrijven. Een symmetrische versleutelingssleutel, een openbare certificaatsleutel en een sleuteluitwisselingsparameter worden niet op één schaal gemeten. Geen ervan dekt of de client de server überhaupt heeft geverifieerd. Het getal is echte informatie, en het is veel smaller dan de marketing eromheen suggereert.
Vraag welke sleutel wordt geteld en wat die beschermt voordat je iets vergelijkt.
Drie sleutels met drie taken
De gegevensversleuteling versleutelt de lading van de tunnel, en de sleutel wordt per sessie opnieuw afgeleid. De openbare sleutel van het certificaat bewijst de identiteit van een eindpunt tijdens de authenticatie. De sleuteluitwisselingsstap, meestal een efemere Diffie-Hellman-variant, legt een gedeeld geheim vast dat geen van beide kanten achteraf kan reconstrueren. Elk heeft zijn eigen sterkteaannames en zijn eigen grootteconventies.
Daarom kunnen 256 naast 2048 naast 32 niet op grootte worden gerangschikt; het zijn antwoorden op verschillende vragen.
Zelfs binnen één rol zegt het getal alleen iets ten opzichte van de gebruikte algoritmefamilie.
Waar het getal helpt, en waar het ophoudt
Binnen één algoritme verhoogt een grotere sleutel de kosten van een brute-force-zoektocht, en gepubliceerde richtlijnen stellen minimums voor certificaatsleutels naarmate de rekenkracht verandert. Dat is een legitieme en smalle vergelijking: AES-128 en AES-256 weerstaan beide een directe aanval met ruime marge, dus het verschil is in de praktijk zelden de beslissende factor.
Buiten die vergelijking voorspelt het getal niets over configuratiefouten, certificaatvalidatie of protocolversie.
Lees de hele onderhandelde suite
Wat een verbinding werkelijk gebruikt, is een suite: een versleutelingsmodus, een integriteits- of geauthenticeerde versleutelingsconstructie, een sleuteluitwisselingsgroep en een authenticatiemethode. Een moderne AEAD-modus met een correcte handshake is een ander voorstel dan een oudere modus met een aparte MAC, zelfs wanneer de vermelde sleutelgrootte identiek is.
openvpn --show-ciphers | head -20 openvpn --show-tls | head -20 openssl x509 -in server.crt -noout -text | grep -E 'Public-Key|Signature Algorithm' wg show
Lees het onderhandelde resultaat en niet het geconfigureerde maximum. Een client die een sterke suite aanbiedt, verbindt nog steeds zwak als de server de zwakkere optie kiest en het profiel dat toestaat. Als prestaties de zorg zijn, meet ze dan op het apparaat en het pad in kwestie, want sleutelgrootte voorspelt de doorvoer slecht zodra hardwareversnelling en pakketgrootte in beeld komen.
De delen die een getal nooit meet
Softwareonderhoud is de eerste omissie. Een tunnel gebouwd op een bibliotheek die geen correcties meer ontvangt, is zwakker dan de sleutelgrootte suggereert, en geen enkele configuratiewaarde herstelt dat. Het gedrag van de operator is de tweede: verbindingsregistraties, accountgegevens en de afhandeling van support staan volledig buiten de cryptografie. Een dienst die meer bewaart dan je verwachtte, wordt niet veiliger door een langere sleutel.
Verificatie van de tegenpartij is de derde en de meest ingrijpende. Een client die elk certificaat accepteert, heeft een sterke versleuteling gewikkeld om een niet-geverifieerde tegenpartij, wat erger is dan een bescheiden versleuteling met correcte validatie. Controleer die drie vóór het getal, en het getal neemt zijn juiste plaats in.