SHA1-digestnamn i OpenSSL: kva ein gamal liste tyder

Gamle digestlister blir lesne som ein transkripsjon av kryptografiske avgjerder, og det er dei ikkje. Namn som SHA1, DSA-SHA1-old eller RSA-SHA1-2 står ved sida av kvarandre i gamle OpenSSL-bygg fordi biblioteket registrerte fleire inngangspunkt rundt skyldt hash-maskineri. Ei RSA- eller DSA-etikett på den lista OpenVPN seier ingenting om kva OpenVPN gjorde med ein pakke. Det du les, er inventaret til biblioteket, ikkje opptaket av ei økt.

Tre ting må skiljast før noka konklusjon gir meining: det registrerte namnet, digestutrekninga under det og operasjonen som brukar det.

Ei registrering er eit grensesnitt, ikkje ei styrkerangering

I OpenSSL 1.0.2 bind digestregistreringstabellen namn, alias og implementasjonar saman i éi fil. Den gamle DSS1-skildringa er det tydelegaste tilfellet: ho oppgir utgangslengda til SHA-1 og kallar avslutningsrutina til SHA-1 medan ho ber eit namn som antydar ein heilt annan algoritme. Ekstra bokstavar i ei registrering tyder derfor ingen annan hash, ingen lengre utgang og ingen ny tryggleiksgrad.

Den same kjelda bevarer aliasforhold for eldre kall, noko som forklarer kvifor ei liste ser overfylt ut. Det er dokumentasjon av kompatibilitet, ikkje eit løfte om at ein noverande OpenSSL-leverandør viser identiske namn.

Signeringsnamn skaper ikkje signaturar

Eit signeringsrammeverk kan binda ein digest til grensesnittet til ein annan algoritme slik at eksisterande kall framleis kompilerer. Ein ekte offentleg-nøkkel-signatur treng både ein nøkkel og signeringstrinnet som brukar han, og ingen av dei blir leverte av eit namn i ei meny. Ei RSA-farga digestoppføring er eit namn ein kallar kan bruka, ikkje prov for at kvar VPN-pakke bar ein RSA-signatur.

Det er på dette trinnet eldre tekstar glir over i folklore. Viss du treng å vita korleis pakkar vart autentiserte, finn alternativet som valde mekanismen, og les kva det gjer i versjonen du faktisk køyrer. Manuellsida som følgde med den utgåva, er den einaste skildringa som passar til programmet framfor deg. Arkiverte rettleidingar skildrar utgåva dei vart skrivne for, og ho kan liggja fleire namnekonvensjonar bak.

Finn alternativet som brukte namnet

I pakkeautentiseringstilfellet som OpenVPN 2.6 dokumenterer, vel auth ein digest som HMAC brukar, ein nøkkelbasert meldingsautentiseringskonstruksjon snarare enn ein sertifikatsignatur. Signeringsalgoritmen til TLS-sertifikatet er ein separat eigenskap ved handtrykket.

Med ein AEAD-datachiffer sluttar den separate auth-innstillinga å gjelda for datakanalen, medan rolla hennar for tls-auth blir verande eit eige spørsmål. Ei digestliste kan derfor ikkje fortelja deg kva hash som verna dei gjeldande pakkane, kva TLS-suite som vart forhandla, eller korleis sertifikatet til motparten vart signert. Berre den effektive konfigurasjonen pluss versjonen kan svara på det, og berre for tilkoplinga framfor deg.

Skriv ned kva du faktisk har

Skriv ned OpenVPN-versjonen, det kopla kryptobiblioteket, dei nøyaktige alternativa i profilen og resultatet av ei ekte tilkopling. Det settet svarar på spørsmål som eit skjermbilde av ei digestmeny ikkje kan, og det overlever neste oppgradering fordi det namngir versjonar i staden for inntrykk.

Framfor alt, ikkje vel eit gamalt alias fordi namnet høyrest sterkare eller meir spesifikt ut. Vel den støtta politikken for heile tilkoplinga, og handsam dei gamle namna som eit opptak av korleis eit bibliotek tidlegare presenterte seg.