AES-256 versus OFB: kies een volledige VPN-cijferconstructie

AES-256 en OFB beantwoorden verschillende vragen, en juist hier gaan cijferreviews mis wanneer ze als concurrerende opties worden behandeld. Het ene benoemt een blokcijfer met een sleutellengte; het andere beschrijft hoe een blokcijfer in een stroom wordt omgezet voor een langer bericht. Een draaiboek voor het kiezen van bescherming moet naar de hele constructie kijken, inclusief hoe de ontvanger een gewijzigd pakket detecteert.

Benoem de vier delen van de constructie

Elke review komt neer op vier vragen: welke primitieve en sleutellengte, hoe berichten ermee worden verwerkt, hoe de ontvanger een ongeoorloofde wijziging weigert en hoe het protocol invoer, sleutels en hun levensduur beheert. Een lijst met bekende namen beantwoordt alleen de eerste. De tweede en derde zijn waar de echte verschillen zitten, en de vierde is waar implementaties stil uiteenlopen. Stel ze in die volgorde en schrijf de antwoorden op.

OFB staat tussen de vertrouwelijkheidsmodi in de NIST-publicatie over blokcijfermodi, en vertrouwelijkheid is alles wat het biedt. Een protocol dat een versleutelingsmodus met een aparte MAC combineert, moet ze correct samenstellen, en een algoritmenaam bewijst die samenstelling niet. Daarom kan de naam van de modus alleen geen implementatiebeslissing beslechten.

De vierde vraag is degene die een operator daadwerkelijk kan verifiëren op het draaiende systeem.

Geef de voorkeur aan een geauthenticeerde constructie

Geauthenticeerde versleuteling levert vertrouwelijkheid en integriteit samen, en AEAD-constructies beschermen ook bijbehorende gegevens tegen wijziging zonder ze te versleutelen. Dat is een eigenschap van pakketbescherming, en het staat los van of iemand zich met succes heeft aangemeld.

De Netgate-richtlijn voor de cryptografische instellingen van OpenVPN wijst voor het datakanaal op AEAD-opties, waaronder AES-GCM, en dat is het soort ondersteund beleid dat je moet volgen. Gebruik de keuzes die de geïnstalleerde release en de peer-clients ondersteunen, in plaats van een historische modusranglijst naar een nieuwe uitrol te kopiëren. Oude compatibiliteit, crypto-backends en offload-ondersteuning beperken wat werkelijk beschikbaar is.

Een ondersteunde constructie verslaat elke keer een slimme samenstelling.

Lees het onderhandelde resultaat, niet het aanbod

Een cijfer op een geaccepteerde lijst zegt niets over de huidige sessie. Lees de onderhandelde datakanaalbescherming bij de client of op de gateway en vergelijk die met het beleid dat je wilde afdwingen. Een configuratie die nog een oude optie voor één oude peer vermeldt, is een compatibiliteitsbeslissing, geen uitspraak over de sessie voor je.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Op een gateway is de equivalente uitvoer de beveiligingsassociatie of de cryptodetails van de verbinding, afhankelijk van het platform. In beide gevallen zijn het aanbod en het resultaat verschillende feiten. Een lijst met een oude optie voor één oude peer betekent niet dat elke sessie die gebruikt, en de sessie die dat wel doet, is wat je moest weten.

Leg beide feiten samen vast, met de datum en de clientversie.

Meet alleen wat vergelijkbaar is

Doorvoer hangt af van de hardware van de eindpunten, de implementatie, versnelling, pakketgroottes en de gekozen configuratie. Noch de sleutellengte noch het woord OFB vertelt je welke uitrol sneller zal zijn. Daarom is een benchmark van een andere site op zijn best een hint over hardware die iemand anders bezit. Je eigen cijfers beginnen bij je eigen eindpunten.

Houd voor een geautoriseerde vergelijking de eindpunten, de werkbelasting en het vereiste beleid constant, en leg de onderhandelde bescherming plus de implementatieversies vast. Beoordeel het resultaat daarna op of de toepassing klaar was, hoeveel die verloor en wat de eindpunten deden, in plaats van cryptokosten af te leiden uit één snelheidstest. Een getal dat onder andere omstandigheden is geproduceerd, is een verhaal, geen meting.

Als een oude peer het beleid niet kan halen, is dat een compatibiliteitsbeslissing voor de eigenaar.

Houd integriteit buiten de ruil

Integriteitscontroles uitschakelen of een niet-geverifieerde server accepteren is geen prestatie-optimalisatie en geen compatibiliteitsoplossing. Het verandert de beveiligingseigenschap waarvoor de constructie is gekozen. Hetzelfde geldt voor het verruimen van de geaccepteerde cijferlijst tot een oude peer verbindt: de verbinding slaagt en het beleid bestaat niet meer.

Schrijf de geaccepteerde constructie en de eigenaar ervan in het draaiboek, zodat de volgende wijziging met een beslissing begint en niet met een voorkeur.

Wat je wilt, is beleid dat beide kanten kunnen afdwingen. Discussiëren over welke naam het sterkst is, is een ander gesprek, en het eindigt meestal zonder beslissing.