Annonsen säger 256 bitar, den andra produkten säger 128 bitar, och slutsatsen verkar självklar tills du märker att talen beskriver olika saker. En symmetrisk chiffernyckel, en certifikats publika nyckel och en nyckelutbytesparameter mäts inte på samma skala. Ingen av dem täcker huruvida klienten över huvud taget verifierade servern. Talet är verklig information, och det är mycket smalare än marknadsföringen runt det antyder.

Fråga vilken nyckel som räknas och vad den skyddar innan du jämför något.

Tre nycklar med tre uppgifter

Datachiffret krypterar tunnelns last, och dess nyckel härleds på nytt för sessionen. Certifikatets publika nyckel bevisar en ändpunkts identitet vid autentiseringen. Nyckelutbytessteget, oftast en efemär Diffie-Hellman-variant, etablerar en gemensam hemlighet som ingen av sidorna i efterhand kan rekonstruera. Var och en har sina egna styrkeantaganden och sina egna storlekskonventioner.

Därför kan 256 intill 2048 intill 32 inte rangordnas efter storlek; de är svar på olika frågor.

Även inom en enda roll säger talet bara något i förhållande till den algoritmfamilj som används.

Där talet hjälper och där det slutar

Inom en algoritm höjer en större nyckel kostnaden för en brute force-sökning, och publicerade riktlinjer sätter miniminivåer för certifikatnycklar i takt med att beräkningskraften förändras. Det är en legitim och smal jämförelse: AES-128 och AES-256 motstår båda direkta angrepp med bred marginal, så skillnaden är sällan den avgörande faktorn i praktiken.

Utanför den jämförelsen förutsäger talet ingenting om konfigurationsfel, certifikatvalidering eller protokollversion.

Läs hela den förhandlade sviten

Det en anslutning faktiskt använder är en svit: ett chifferläge, en integritets- eller autentiserad krypteringskonstruktion, en nyckelutbytesgrupp och en autentiseringsmetod. Ett modernt AEAD-läge med ett korrekt handskakning är ett annat erbjudande än ett äldre läge med en separat MAC, även när den angivna nyckelstorleken är identisk.

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

Läs det förhandlade resultatet i stället för det konfigurerade maximumet. En klient som erbjuder en stark svit ansluter ändå svagt om servern väljer det svagare alternativet och profilen tillåter det. Om prestanda är bekymret, mät den på enheten och vägen i fråga, eftersom nyckelstorlek är en dålig förutsägelse av genomströmningen när hårdvaruacceleration och paketstorlek kommer in i bilden.

De delar som ett tal aldrig mäter

Programvaruunderhåll är den första utelämningen. En tunnel byggd på ett bibliotek som slutat ta emot rättelser är svagare än nyckelstorleken antyder, och inget konfigurationsvärde reparerar det. Operatörens beteende är det andra: anslutningsregister, kontodata och supporthantering ligger helt utanför kryptografin. En tjänst som behåller mer än du förväntade dig blir inte säkrare av en längre nyckel.

Verifiering av motparten är den tredje och den mest konsekvensrika. En klient som accepterar vilket certifikat som helst har ett starkt chiffer virat runt en oautentiserad motpart, vilket är sämre än ett blygsamt chiffer med korrekt validering. Kontrollera dessa tre före talet, och talet intar sin rättmätiga plats.

Relaterade artiklar