Statinio rakto failo bitų skaičius nėra OpenVPN šifro stiprumas

Skaitytuvas ar kolega parodo bitų skaičių, įspausdintą statinio OpenVPN rakto failo viduje, ir klausia, kodėl tunelis nenaudoja tokio dydžio šifro. Klausimas skamba pagrįstai, o atsakymas nėra skaičius: antraštė skaičiuoja saugomą rakto medžiagą, o šifras sunaudoja tik tą dalį, kurios reikalauja jo rakto dydis. Priimant šią sumą kaip stiprumo nuostatą, atsiranda pakeitimai, kurie nieko nekeičia. Formatas buvo sukurtas talpinti daugiau medžiagos, nei sunaudoja bet kuris atskiras algoritmas.

Čia susimaišo du klausimai: kiek rakto medžiagos failas saugo ir koks stiprus yra suderintas šifras. Tunelį apibūdina tik antrasis.

Ką iš tikrųjų skaičiuoja antraštės skaičius

Konteineris serializuoja šifro medžiagą ir HMAC medžiagą kaip atskiras struktūras, o dvikryptė forma laiko du tokius rinkinius, kad kiekviena kryptis galėtų turėti savo raktus. Rašantis kodas išspausdintą skaičių išveda iš serializuotų struktūrų skaičiaus, jų dydžio ir aštuonių bitų vienam baitui. Tai aritmetika apie saugyklą, o ne teiginys, kad vienas šifras sunaudoja kiekvieną saugomą baitą. Antraštė taip pat fiksuoja didžiausią šifro medžiagos paskirstymą, kad bibliotekos pakeitimas negalėtų tyliai pakeisti formato matmenų.

Palyginkite tai su sertifikato raktu, kur bitų skaičius tikrai apibūdina vieno objekto dydį. 4,096 bitų RSA raktas ir rakto failas, kurio antraštėje parašyta 4,096 bitų, yra skirtingi dirbiniai su skirtingais darbais, o jų sulyginimas kaip dviejų vieno reguliatoriaus nuostatų veda prie blogų išvadų.

Du raktų rinkiniai viename faile

Kiekviena failo pusė tiekia šifravimo ir autentifikavimo medžiagą, nes iš anksto bendrinamo rakto režimas saugo paketus abiem kryptimis tais atskirais gabalais. Aktyvus šifras naudoja tik tuos baitus, kurių reikalauja jo rakto dydis, o santrauka naudoja savo išvesties dydį, todėl naudingas stiprumas kyla iš parinkčių, o ne iš failo ilgio. Šešioliktainio bloko ilginimas neprašo sukonfigūruoto algoritmo sunaudoti daugiau jo. Komentaro redagavimas didesniu skaičiumi pakeičia dar mažiau.

Jei tikrai norite ilgesnio rakto, keistina nuostata yra šifras arba santrauka, o generatorius sukuria tai, ko reikia pasirinktiems algoritmams.

Perskaičius profilį paaiškėja, kurį režimą turite

Tas pats failo formatas tarnauja dviem gana skirtingiems darbams, ir tik profilis pasako, kurį turite. Sena secret eilutė failą paverčia vienintele tunelio rakto medžiaga, o tls-auth arba tls-crypt paverčia jį valdymo kanalo apsauga šalia sertifikatų. Nė vienas naudojimas nepaverčia jo kliento sertifikato privačiuoju raktu, kad ir kaip panašiai blokas atrodo. Prieš generuodami pakaitalą nustatykite parinktį ir versiją, o vietoj simbolių pridėjimo naudokite dokumentuotą generatorių.

Šis skirtumas taip pat lemia reakciją į atskleidimą. Nutekėjęs tls-auth raktas neatskleidžia sesijos raktų, bet leidžia užpuolikui įterpti valdymo kanalo srautą, todėl jį vis tiek reikia pakeisti. Nutekėjęs secret raktas yra blogiau, nes jis buvo medžiaga, saugojusi pačius duomenis.

Ką turėtų užfiksuoti saugumo apžvalga

Užfiksuokite tris dalykus atskirai: suderintą duomenų kanalo apsaugą, valdymo kanalo apsaugą ir tai, kaip partneriai autentifikuojasi. Eilutė kaip data-ciphers AES-256-GCM apibūdina tik pirmąjį, o ataskaita, kuri ten sustoja, negali atsakyti, ar valdymo kanalas apskritai apsaugotas. Statinio rakto failas priklauso antrajai kategorijai, kai naudojamas su tls-auth arba tls-crypt, ir nė vienai, kai nenaudojamas. Recenzentai, sumaišantys kategorijas, prašo didesnio rakto failo tada, kai iš tikrųjų nori stipresnio šifro.

Jei failas buvo atskleistas, pasukite jį ir perskirstykite patvirtintu kanalu. Simbolių pridėjimas prie kompromituotos paslapties nėra pasukimas, ir jis palieka atskleistą medžiagą galiojančią.

Laikykite pasukimo įrašą kartu su profiliu, kuriam jis priklauso. Kita apžvalga paklaus kuris raktas kokį laikotarpį saugojo, ir antraštė į tai neatsakys.