OpenVPN EC vs ED: waarom de namen geen sterkteladder zijn

Zet ec, ed, ecdh, ecdsa, auth en een TLS-cipherlijst naast elkaar in één profiel, en het bestand begint eruit te zien als een sterkteknop met zes standen. Maar dat is het niet. Elke naam beantwoordt een andere vraag, en twee profielen die in één daarvan verschillen zijn niet per se sterker of zwakker dan elkaar. De namen op hun werk sorteren kost ongeveer vijf minuten en voorkomt het meeste van de slechte aanpassingen die mensen aan een werkende configuratie doen.

De sortering hieronder begint bij de verwarring zelf en werkt dan naar buiten toe, naar de delen van een profiel die echt bepalen wat je verkeer beschermt. Elke sectie neemt om de beurt één verkeerde lezing en laat zien waaraan de naam werkelijk vastzit.

Twee letters, twee verschillende vragen

Het paar dat de meeste discussie veroorzaakt is EC en ED, en de discussie gaat er meestal van uit dat ze rivaliserende antwoorden op één vraag zijn. Ze liggen niet eens op dezelfde as. EC beschrijft een familie van wiskunde: cryptografie met elliptische krommen, waarbij de veiligheid komt van de moeilijkheid van een discrete logaritme op een kromme en niet in een groot eindig veld.

ED beschrijft een krommevorm binnen die familie. Twisted Edwards-krommen zijn een weergave die is gekozen om snelheid en om weerstand tegen verschillende implementatiefouten, en Ed25519 is de naam die mensen meestal bedoelen. De kromme is geen concurrent van cryptografie met elliptische krommen; het is één manier om een elliptische kromme te schrijven. ED lezen als "de nieuwere, sterkere EC" is de eerste verkeerde afslag, en alles daarna is meestal fout in dezelfde richting.

Ondertekenen en uitwisselen zijn aparte taken

Zodra de familievraag is opgelost, splitsen de overgebleven namen zich in twee kolommen die elkaar nooit vervangen. De ene kolom ondertekent, de andere komt een gedeeld geheim overeen.

Zowel EdDSA als ECDSA ondertekent, maar het zijn verschillende schema's met verschillende sleutelformaten, dus een certificaat dat voor het ene is uitgegeven is niet als het andere te gebruiken. EdDSA is gedefinieerd voor een kleine reeks krommen; P-256 is er daar geen van, daarom wordt een P-256-certificaat met ECDSA geverifieerd en nooit met Ed25519.

De uitwisselingskolom heeft geen equivalent dat EdDH heet. Efemere overeenstemming op een Curve25519-sleutel is X25519, en dat is ECDH met een bepaalde kromme, precies zoals bij P-256. Ed25519 betekent strikt genomen het ondertekeningsschema, hoewel de naam losjes voor de uitwisseling wordt gebruikt omdat de twee krommen verwant zijn: de Edwards-vorm voor het ondertekenen en de Montgomery-vorm voor X25519 beschrijven dezelfde onderliggende groep.

Waarom een EC-profiel geen dh-bestand heeft

Een dh-bestand bevat vooraf gegenereerde parameters voor Diffie-Hellman in een eindig veld, en die parameters bestaan omdat een groot priemgetal en een generator ergens vandaan moeten komen. Een uitwisseling op een elliptische kromme heeft ze niet nodig: de genoemde kromme is de parameterset, en beide kanten kennen die al. Dat is de hele reden waarom een EC-profiel de richtlijn kan weglaten.

Twee situaties leveren nog steeds een dh-regel op in een profiel dat er verder modern uitziet. De eerste is een tweede luisteraar of een oudere peer die echt over groepen in een eindig veld onderhandelt. De tweede is achtergebleven tekst die uit een sjabloon uit het RSA-tijdperk is gekopieerd en nooit verwijderd. Een profiel dat een kromme voor de uitwisseling noemt en nog steeds een dh-bestand van 2048 bits laadt, is daardoor niet veiliger; het draagt een ongebruikt artefact mee.

TLS 1.3 haalde de sleuteluitwisseling uit de naam

Vergelijk TLS_AES_256_GCM_SHA384 met TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 en de kortere naam lijkt een downgrade. Het is een hernoeming, en de reden is structureel: TLS 1.3 verwijderde statische RSA en Diffie-Hellman-sleuteluitwisseling in een eindig veld, dus een efemere uitwisseling op een elliptische kromme is de enige overgebleven niet-PSK-optie. Die in elke suite benoemen zou hetzelfde feit een dozijn keer herhalen.

Het certificaattype verdween om een verwante reden uit de naam. In 1.3 authentiseert het certificaat de handshake-handtekening, niet de sleutelovereenkomst, dus het selecteert de suite niet meer. Daarom bestaat er in de configuratie een aparte cipherlijst voor 1.3: de suites zijn hernoemd en herschikt, niet verzwakt.

Eén gevolg is de moeite waard om ronduit te zeggen. ECDHE is een sleuteluitwisselingsalgoritme en nooit een cipher. Een suite die als "elliptisch" wordt beschreven zegt iets over hoe de twee peers tot een gedeelde sleutel kwamen, en niets over wat daarna de payload versleutelt.

auth authentiseert pakketten, niet payloads

De richtlijn auth kiest de HMAC-digest die pakketten authentiseert, en de historische standaardwaarde is SHA1. Bij een datacipher die geen AEAD is, berekent OpenVPN de digest over de ciphertekst en voegt die toe, een encrypt-dan-MAC-opzet die het knoeien met padding onpraktisch maakt.

De mythe hier is dat het verhogen van auth naar SHA512 de tunnel harder maakt. Het verhoogt de sterkte van de versleuteling niet, en als de onderhandelde datacipher een AEAD-modus is zoals AES-256-GCM, wordt de digest helemaal niet op datapakketten toegepast. De GCM-tag authentiseert ze al, en de auth-waarde blijft over voor het HMAC van het controlekanaal en voor elke cipher zonder AEAD die nog wordt gebruikt.

De richtlijn doet er dus toe, maar ze doet er toe op een smallere plek dan haar positie in het bestand suggereert. Controleren welke cipher daadwerkelijk is onderhandeld vertelt je of ze sowieso van toepassing is.

Lees het profiel per kolom, niet per rang

Drie vragen scheiden de lagen netjes, en elk wordt beantwoord door een ander deel van de onderhandelde sessie. Welke cipher beschermt de payload? Welke tag of digest staat borg voor elk pakket, en heeft de gebruikte cipher er sowieso een nodig? Wiens certificaat sloot de handshake, en is het controlekanaal bovendien beschermd door tls-auth of tls-crypt?

Niets in het EC- of ED-label beslecht een van die drie, en een suitenaam alleen beslecht er ook geen. Het onderhandelde resultaat is het enige bewijs, dus lees dat in plaats van de sterkte uit het vocabulaire af te leiden:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

De eerste opdracht vertelt je welk ondertekeningsschema je certificaat werkelijk gebruikt, en dat is de enige betrouwbare manier om te weten of je ECDSA of Ed25519 draait. De tweede toont de controlekanaalregel die de client voor de sessie heeft vastgelegd, inclusief de TLS-versie en de suite waarop hij uitkwam. Als een profielwijziging niet met een van die twee uitvoer kan worden gerechtvaardigd, is het waarschijnlijk een wijziging van een naam en niet van een eigenschap.