Varför AES-256 inte beskriver en VPN-krypteringssvit
En svit fyller fyra roller: bulkkryptering, integritet, nyckeluppsättning och autentisering av motparten. Ett chiffrenamn täcker bara en av dem, på ett lager.
Fråga vilken kryptering en VPN använder och svaret kommer oftast som ett ord: AES-256, eller ChaCha20, eller kanske WireGuard. Det svaret namnger en komponent i ett lager, medan det som faktiskt skyddar anslutningen är en uppsättning algoritmer som fyller fyra olika roller. Att blanda ihop komponenten med arrangemanget är det vanligaste misstaget i dessa samtal, och det ger jämförelser som inte går att avgöra.
Fyra uppgifter i en anslutning
Bulkkryptering gör klartext till chiffertext för datakanalen, och nyckeln härleds i stället för att överföras. Integritetsskydd upptäcker ändring, vilket är en separat uppgift även när en enda konstruktion gör båda. Nyckeluppsättning producerar det gemensamma trafikmaterialet, och autentisering av motparten avgör vem som finns i andra änden. Saknas någon av dem är anslutningen inte säker, hur stark den kvarvarande delen än är.
Vissa konstruktioner slår ihop två roller. AES-GCM och ChaCha20-Poly1305 är autentiserade krypteringskonstruktioner, så konfidentialitet och integritet kommer tillsammans; AES-CBC är det inte och behöver en separat meddelandeautentiseringskod med egen nyckel. Därför läser man fel när man läser ett förslag som en påse oberoende tal, för de som är designade som par.
Rollerna ligger också på olika lager, och därför kan samma ord betyda olika saker i två produkter. Ett blockchiffer i ESP och ett blockchiffer i TLS är samma primitiv i olika förhandlingar med olika krav. Därför kan det vara värre att citera en primitiv utan dess läge och lager än att inte citera något.
Varför ett chiffrenamn nästan inte säger något
Ta uttrycket AES-256 på allvar ett ögonblick: det anger ett blockchiffer och en nyckelstorlek. Det säger ingenting om driftläget, om integritet tillhandahålls, hur nycklar upprättades eller hur motparten autentiserades. Två produkter kan båda annonsera AES-256 och skilja sig i allt annat, inklusive en som parar det med ett oautentiserat läge och en som använder ett AEAD-läge med modern nyckelutbyte.
TLS 1.3 lyfte in denna åtskillnad i standarden, vilket är en användbar rättelse för alla som lärt sig det äldre ordförrådet. Dess chiffersviter namnger bara AEAD och hashen, medan nyckelutbytesgrupper och signaturalgoritmer förhandlas som egna parametrar. Därför går ett TLS 1.3-svitnamn inte att jämföra med ett TLS 1.2-svitnamn på lika villkor, även om båda förekommer i samma fält i en konfigurationsfil. En granskare som jämför de två strängarna direkt drar en slutsats som protokollet inte stöder. Läs också den förhandlade gruppen och signaturparametrarna, annars är jämförelsen ofullständig.
WireGuard väljer motsatt väg och tar bort förhandlingen nästan helt: protokollet anger en fast algoritmuppsättning, så två implementationer antingen samverkar eller inte. Det är ett legitimt designval, och det betyder också att frågan vilken svit WireGuard förhandlar inte har ett svar som är värt att jämföra. Om du granskar det, läs specifikationen en gång och granska sedan nyckelhanteringen runt den i stället för förhandlingen.
Lagret avgör ordförrådet
En IPsec-driftsättning förhandlar två gånger: ett IKE-förslag för kontrollkanalen och en ESP-transform för data, och de två kan lagligt skilja sig. Att läsa det första och anta att det beskriver det andra är en vanlig källa till förvirring vid en granskning, eftersom konfigurationsfilen nämner båda och den intressanta är den andra.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Ett namn som finns i ett bibliotek implementeras inte automatiskt för en annan dataväg. Därför är påståendet att vår produkt stöder AES-256 svagare än det låter, och därför löses ett interoperabilitetsproblem vanligen genom att hitta det underhållna snittet i stället för att aktivera varje gammal algoritm på båda sidor.
Specifikationen för TLS 1.3 är det tydligaste publicerade exemplet på åtskillnaden, eftersom den definierar sviten som ett par och flyttar resten till deras egen förhandling. När den formen är bekant läses IPsec-förslaget och den enda fasta WireGuard-uppsättningen som varianter av samma idé.
Läs det förhandlade resultatet och stanna sedan
Ett konfigurerat förslag är inte bevis på vad två parter valde. Den levande sessionen bär svaret, och varje vanlig implementation kan rapportera det utan att fånga paket.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showLäs i utdata de valda algoritmerna i stället för den erbjudna listan. Om svaret är svagare än policyn avsåg hör rättelsen hemma i förslagets konfiguration på endera sidan, och en avvikelse visar sig i moderna implementationer vanligen som en misslyckad förhandling snarare än en tyst nedgradering.
Kom sedan ihåg vad sviten inte täcker. Rutter, appbehörigheter, loggning och lagring är egna beslut med egen granskning, och ett kompatibelt kryptografiskt arrangemang säger ingenting om dem. Chifferdiskussionen är värd att föra, men den besvarar en snävare fråga än den de flesta faktiskt ställer.
Håll ordförrådet exakt och argumentet blir kortare. En svit är en uppsättning roller på ett lager, ett chiffer är en komponent, och det förhandlade resultatet är det enda som beskriver den anslutning du faktiskt har. Allt annat i jämförelsen är dekoration.