Simmetriese vs. publieke-sleutel-enkripsie in 'n VPN: wat elkeen doen

Mense beskryf 'n VPN as „die een wat publieke-sleutel-enkripsie gebruik” en stel hulle dan voor dat elke pakkie met die bediener se sertifikaat toegesluit word. Daardie beeld is verkeerd op 'n manier wat saak maak wanneer jy 'n konfigurasielêer of 'n pakkie-opname lees. Die publieke-sleutel-helfte van 'n VPN gaan daaroor om te bewys wie die eweknie is en om oor geheime materiaal saam te stem; die simmetriese helfte is wat die verkeer werklik beskerm, pakkie na pakkie, vir die lewe van die sessie.

Die twee helftes het verskillende lewensduur, verskillende foutmodusse en verskillende dinge wat jy veilig kan publiseer. Sodra jy hulle skei, hou vrae soos „dis RSA 2048 swakker as AES-128” op om verwarrend te wees, want hulle was nooit in die eerste plek vergelykbaar nie.

Drie bewerkings wat saamgegooi word

Publieke-sleutel-kriptografie is 'n sambreel oor minstens drie afsonderlike bewerkings. 'n Handtekening bewys dat die houer van 'n private sleutel 'n bepaalde boodskap goedgekeur het. Sleutelooreenkoms laat twee eweknieë 'n gedeelde geheim aflei uit waardes wat hulle in die openbaar uitruil. Publieke-sleutel-enkripsie verberg data onder iemand se publieke sleutel sodat net die private sleutel dit kan oopmaak.

VPN-handskuddings gebruik meestal die eerste twee. 'n Sertifikaat is nie 'n enkripsiesleutel nie; dit is 'n ondertekende verklaring wat 'n naam aan 'n publieke sleutel bind, wat die ander kant laat besluit of die sleutel wat hy pas ontvang het, vertrou kan word. TLS 1.3-sleutelvestiging, byvoorbeeld, berus op (EC)DHE-sleutelooreenkoms plus sertifikaathandtekeninge, nie op die enkripsie van die sessie met die bediener se publieke sleutel nie.

Wat die handskud werklik oplewer

In 'n moderne handskud genereer elke kant 'n efemere sleutelpaar, ruil die publieke helftes uit en bereken 'n gedeelde geheim wat nooit oor die draad gaan nie. Daardie geheim word dan deur 'n sleutelafleidingsfunksie gestuur om afsonderlike sleutels vir elke rigting te produseer, plus die nonces en IV-materiaal wat die rekordlaag nodig het. WireGuard doen dit met sy op Noise gebaseerde konstruksie; TLS 1.3 doen dit met HKDF oor die handskudtranskripsie.

Die langtermyn-aanmelding — sertifikaat en private sleutel, of 'n statiese WireGuard-sleutel — verifieer daardie uitruiling. Dit onderteken of meng in die transkripsie sodat 'n vreemdeling nie die handskud in die eweknie se plek kan voltooi nie. Daarna doen die aanmelding nie werk per pakkie nie. As dit wel so was, sou elke pakkie 'n private-sleutel-bewerking nodig hê, en 'n besige tonnel sou beperk word deur die stadigste bewerking in die stapel.

Twee newe-effekte volg. Eerstens is die sessiesleutels elke keer vars, en daarom kan 'n aanvaller wat later die langtermyn-sleutel steel nie sessies ontsyfer wat vroeër opgeneem is nie, mits die ooreenkoms efemeer was. Tweedens kompromitteer 'n uitgelekte sessiesleutel een sessie, nie die identiteit nie.

Waarom groot datavolumes simmetriese sleutels gebruik

Simmetriese syfers hanteer volume goed: AES-GCM of ChaCha20-Poly1305 verwerk elke pakkie met 'n sleutel wat reeds in die geheue is, verifieer die kop en verhoog 'n teller. Die ontvangende kant kontroleer die nonce en die verifikasie-etiket en gooi alles weg wat faal of herhaal. Dit is goedkoop genoeg om teen lynspoed op gewone hardeware te loop, en dieselfde konstruksie gee vertroulikheid en integriteit in een deurgang.

Die konstruksie is ook waar die meeste implementeringsfoute woon. 'n Herhaalde nonce in GCM breek vertroulikheid en egtheid tegelyk, daarom lei protokolle sleutels per rigting af en hou 'n eksplisiete teller of epog by. As jy 'n pakkie-opname lees en die ciphertext-lengte stem ooreen met die plaintext plus 'n vaste oorhoofse koste, is dit die simmetriese laag wat werk, nie 'n publieke-sleutel-bewerking per pakkie nie.

Lewensduur, sleutelhernuwing en voorwaartse geheimhouding

Sessiesleutels is bedoel om te verval. TLS 1.3 laat 'n KeyUpdate-boodskap toe om die verkeersleutels te rol; WireGuard hernu 'n sessie ná 'n gekonfigureerde tyd of boodskaptelling en hou die ou een kortliks vir pakkies onderweg. OpenVPN heronderhandel sy datakanale se sleutels volgens 'n skedule, met reneg-sec wat die interval beheer.

Nie een van daardie rotasie is dieselfde as die hernuwing van 'n sertifikaat nie. 'n Sertifikaat kan 'n jaar lank geldig wees terwyl die sessiesleutels elke paar minute verander, en 'n sertifikaat kan vervang word sonder om aan die lopende tonnel se sleutels te raak. Wanneer jy 'n vervaldatum beplan, vra watter objek jy roteer; die antwoord bepaal of kliënte weer aansluit of bloot sleutels hernu.

Konfigurasies en diagnostiek lees sonder om objekte te vermeng

In die praktyk kies jy 'n volledige protokol en sy ondersteunde primitiewe, nie om jou eie saam te stel nie. OpenVPN se --tls-crypt-sleutel beskerm die beheerkanaal; die datakanaal gebruik onderhandelde simmetriese syfers. WireGuard se PrivateKey- en PublicKey-inskrywings is identiteitsmateriaal, terwyl sy vervoersleutels intern afgelei word. Om daardie velde as dieselfde soort geheim te lees, lei tot foute soos om 'n publieke sleutel te plak waar 'n private een hoort.

Hou publieke materiaal apart van private. 'n Sertifikaat, 'n WireGuard-publieke sleutel en 'n vingerafdruk is veilig om in 'n kaartjie te deel. 'n Private sleutel, 'n vooraf gedeelde sleutel en 'n uitgevoerde sessiesleutel is nie. Wanneer jy sterkte vergelyk, vergelyk binne 'n tipe: 'n elliptiese-kurwe-identifiseerder, 'n RSA-modulusgrootte en 'n AES-sleutelgrootte meet verskillende dinge onder verskillende aannames. Die TLS 1.3-spesifikasie is 'n nuttige verwysing vir hoe die twee lae inmekaar pas, selfs wanneer jou tonnel nie TLS is nie.