OpenVPN EC vs ED: hoekom die name nie ’n ranglys van sterkte is nie

Plaas ec, ed, ecdh, ecdsa, auth en ’n TLS-syferlys langs mekaar in een profiel, en die lêer begin soos ’n sterktewiel met ses posisies lyk. Dit is nie. Elke naam beantwoord ’n ander vraag, en twee profiele wat in een daarvan verskil, is nie noodwendig sterker of swakker as mekaar nie. Om die name volgens hul werk te sorteer neem omtrent vyf minute en voorkom die meeste van die slegte wysigings wat mense aan ’n werkende konfigurasie maak.

Die sortering hieronder begin by die verwarring self en werk dan uitwaarts na die dele van ’n profiel wat werklik bepaal wat jou verkeer beskerm. Elke afdeling neem op sy beurt een mislees en wys waaraan die naam werklik gekoppel is.

Twee letters, twee verskillende vrae

Die paar wat die meeste argument veroorsaak, is EC en ED, en die argument aanvaar gewoonlik dat hulle mededingende antwoorde op een vraag is. Hulle is nie eens op dieselfde as nie. EC beskryf ’n familie van wiskunde: elliptiese-kurwe-kriptografie, waar die sekuriteit kom van die moeilikheid van ’n diskrete logaritme op ’n kurwe eerder as in ’n groot eindige veld.

ED beskryf ’n kurwevorm binne daardie familie. Twisted Edwards-kurwes is ’n voorstelling wat gekies is vir spoed en vir weerstand teen verskeie implementeringsfoute, en Ed25519 is die naam wat mense gewoonlik bedoel. Die kurwe is nie ’n mededinger vir elliptiese-kurwe-kriptografie nie; dit is een manier om ’n elliptiese kurwe te skryf. Om ED te lees as "die nuwer, sterker EC" is die eerste verkeerde draai, en alles daarna is geneig om in dieselfde rigting verkeerd te wees.

Ondertekening en uitruiling is aparte take

Sodra die familie-vraag besleg is, val die oorblywende name in twee kolomme uiteen wat nooit mekaar vervang nie. Een kolom onderteken, die ander kom ooreen op ’n gedeelde geheim.

EdDSA en ECDSA onderteken albei, maar hulle is verskillende skemas met verskillende sleutelformate, so ’n sertifikaat wat vir een uitgereik is, is nie as die ander bruikbaar nie. EdDSA is vir ’n klein stel kurwes gedefinieer; P-256 is nie een daarvan nie, en daarom verifieer ’n P-256-sertifikaat met ECDSA en nooit met Ed25519 nie.

Die uitruilkolom het geen ekwivalent met die naam EdDH nie. Efemere ooreenkoms op ’n Curve25519-sleutel is X25519, en dit is ECDH met ’n bepaalde kurwe, presies soos met P-256. Ed25519 beteken streng gesproke die handtekeningstelsel, hoewel die naam losweg vir die uitruiling gebruik word omdat die twee kurwes verwant is: die Edwards-vorm vir ondertekening en die Montgomery-vorm vir X25519 beskryf dieselfde onderliggende groep.

Waarom ’n EC-profiel geen dh-lêer het nie

’n dh-lêer bevat vooraf gegenereerde parameters vir eindige-veld Diffie-Hellman, en daardie parameters bestaan omdat ’n groot priemgetal en ’n generator êrens vandaan moet kom. ’n Elliptiese-kurwe-uitruiling het hulle nie nodig nie: die genoemde kurwe is die parameterstel, en beide kante weet dit alreeds. Dit is die hele rede waarom ’n EC-profiel die riglyn kan weglaat.

Twee situasies lewer steeds ’n dh-reël in ’n profiel wat andersins modern lyk. Die eerste is ’n tweede luisteraar of ’n ouer eweknie wat werklik eindige-veldgroepe onderhandel. Die tweede is oorblywende teks wat uit ’n RSA-era-sjabloon gekopieer en nooit verwyder is nie. ’n Profiel wat ’n kurwe vir die uitruiling noem en steeds ’n 2048-bis dh-lêer laai, is nie veiliger omdat dit dit gedoen het nie; dit dra ’n ongebruikte artefak.

TLS 1.3 het die sleuteluitruiling uit die naam verwyder

Vergelyk TLS_AES_256_GCM_SHA384 met TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 en die korter naam lyk soos ’n afgradering. Dit is ’n hernoeming, en die rede is struktureel: TLS 1.3 het statiese RSA en eindige-veld Diffie-Hellman-sleuteluitruiling verwyder, so ’n efemere elliptiese-kurwe-uitruiling is die enigste nie-PSK-opsie wat oorbly. Om dit in elke suite te noem, sou dieselfde feit ’n dosyn keer herhaal.

Die sertifikaattipe het om ’n verwante rede uit die naam verdwyn. In 1.3 verifieer die sertifikaat die handdruk-handtekening, nie die sleutelooreenkoms nie, so dit kies nie meer die suite nie. Dit is ook waarom daar in die konfigurasie ’n aparte syferlys vir 1.3 bestaan: die suites is hernoem en herorganiseer, nie verswak nie.

Een gevolg is die moeite werd om duidelik te stel. ECDHE is ’n sleuteluitruilalgoritme en nooit ’n syfer nie. ’n Suite wat as "ellipties" beskryf word, sê iets oor hoe die twee eweknieë by ’n gedeelde sleutel uitgekom het, en niks oor wat dan die nutslading versleutel nie.

auth verifieer pakkette, nie nutsladings nie

Die auth-riglyn kies die HMAC-verteerding wat pakkette verifieer, en sy historiese verstek is SHA1. Met ’n nie-AEAD-datasyfer bereken OpenVPN die verteringswaarde oor die syferteks en voeg dit by, ’n versleutel-dan-MAC-reëling wat dit onprakties maak om die opvulling te manipuleer.

Die mite hier is dat om auth na SHA512 te verhoog die tonnel harder maak. Dit verhoog nie die sterkte van die versleuteling nie, en as die onderhandelde datasyfer ’n AEAD-modus soos AES-256-GCM is, word die verteringswaarde glad nie op datapakkette toegepas nie. Die GCM-etiket verifieer hulle reeds, en die auth-waarde word gelaat vir die beheerkanal se HMAC en vir enige nie-AEAD-syfer wat nog gebruik word.

Dus maak die riglyn saak, maar dit maak saak op ’n smaller plek as wat sy posisie in die lêer voorstel. Om te kyk watter syfer werklik onderhandel is, sê jou of dit hoegenaamd van toepassing is.

Lees die profiel volgens kolom, nie volgens rang nie

Drie vrae skei die lae skoon, en elkeen word deur ’n ander deel van die onderhandelde sessie beantwoord. Watter syfer beskerm die nutslading? Watter etiket of verteringswaarde staan vir elke pakket in, en vereis die syfer in gebruik hoegenaamd een? Wie se sertifikaat het die handdruk gesluit, en word die beheerkanal bykomend deur tls-auth of tls-crypt beskerm?

Niks in die EC- of ED-etiket beslis enige van daardie drie nie, en ’n suitenaam op sy eie beslis ook nie een van hulle nie. Die onderhandelde resultaat is die enigste bewyse, so lees dit eerder as om sterkte uit woordeskat af te lei:

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

Die eerste opdrag sê vir jou watter handtekeningstelsel jou sertifikaat werklik gebruik, wat die enigste betroubare manier is om te weet of jy ECDSA of Ed25519 gebruik. Die tweede wys die beheerkanal-reël wat die kliënt vir die sessie aangeteken het, insluitend die TLS-weergawe en die suite waarop dit besluit het. As ’n profielwysiging nie deur een van daardie twee uitsette geregverdig kan word nie, is dit waarskynlik ’n verandering aan ’n naam eerder as aan ’n eienskap.