OpenSSL SHA1-digestaj nomoj: kion signifas malnova listo

Malnovaj digestlistoj legiĝas kiel transskribo de kriptografiaj decidoj, kaj ili ne estas tio. Nomoj kiel SHA1, DSA-SHA1-old aŭ RSA-SHA1-2 staras unu apud la alia en malnovaj OpenSSL-konstruoj ĉar la biblioteko registris plurajn enirpunktojn ĉirkaŭ rilata haŝa maŝinaro. Etikedo RSA aŭ DSA en tiu listo diras nenion pri tio, kion OpenVPN faris al pako. Tio, kion vi legas, estas la inventaro de la biblioteko, ne la registro de sesio.

Tri aferojn oni devas apartigi antaŭ ol iu ajn konkludo havas sencon: la registritan nomon, la digestan kalkulon sub ĝi kaj la operacion, kiu ĝin konsumas.

Registraĵo estas interfaco, ne taksado de forteco

En OpenSSL 1.0.2 la digestregistra tabelo kunligas nomojn, kaŝnomojn kaj efektivigojn en unu dosiero. La malnova DSS1-priskribilo estas la plej klara kazo: ĝi raportas la eligan longon de SHA-1 kaj vokas la finfaran rutinon de SHA-1, dum ĝi portas nomon, kiu sugestas tute alian algoritmon. Pliaj literoj en registraĵo do implicas neniun alian haŝon, neniun pli longan eligon kaj neniun novan sekurecnivelon.

La sama fonto konservas kaŝnomajn rilatojn por pli malnovaj vokantoj, kio klarigas, kial listo aspektas plenplena. Tio estas dokumentado de kongruo, ne promeso, ke nuntempa OpenSSL-provizanto montras identajn nomojn.

Subskribaj nomoj ne kreas subskribojn

Subskriba kadro povas ligi digeston al la interfaco de alia algoritmo, por ke ekzistantaj vokantoj daŭre kompiliĝu. Vera publikkleja subskribo bezonas kaj ŝlosilon kaj la subskriban paŝon, kiu ĝin uzas, kaj neniun el ili liveras nomo en menuo. RSA-nuanca digesto-ero estas nomo, kiun vokanto rajtas uzi, ne pruvo, ke ĉiu VPN-pako portis RSA-subskribon.

Ĝuste ĉe ĉi tiu paŝo pli malnovaj tekstoj glitas en folkloron. Se vi bezonas scii, kiel pakoj estis aŭtentikigitaj, trovu la opcion, kiu elektis la mekanismon, kaj legu, kion ĝi faras en la versio, kiun vi efektive rulas. La manlibra paĝo liverita kun tiu eldono estas la sola priskribo, kiu kongruas kun la programo antaŭ vi. Arkivitaj gvidiloj priskribas la eldonon, por kiu ili estis verkitaj, kaj tiu povas resti plurajn nomigajn konvenciojn malantaŭe.

Trovu la opcion, kiu konsumis la nomon

En la paka aŭtentikiga kazo dokumentita de OpenVPN 2.6, auth elektas digeston uzatan de HMAC, ŝlosilan mesaĝaŭtentikigan konstruaĵon anstataŭ certifikatan subskribon. La subskriba algoritmo de la TLS-atestilo estas aparta eco de la manpremo.

Ĉe AEAD-datumĉifrado la aparta auth-agordo ĉesas validi por la data kanalo, dum ĝia rolo por tls-auth restas aparta demando. Digesta listo do ne povas diri al vi, kiu haŝo protektis la nunajn pakojn, kiu TLS-suito estis intertraktita aŭ kiel estis subskribita la atestilo de la partnero. Nur la efektiva agordo kune kun la versio povas respondi tion, kaj nur por la konekto antaŭ vi.

Notu, kion vi efektive havas

Notu la version de OpenVPN, la ligitan kriptan bibliotekon, la precizajn opciojn en la profilo kaj la rezulton de reala konekto. Tiu aro respondas demandojn, kiujn ekrankopio de digesta menuo ne povas, kaj ĝi postvivos la sekvan ĝisdatigon ĉar ĝi nomas versiojn anstataŭ impresojn.

Super ĉio, ne elektu malnovan kaŝnomon ĉar ĝia nomo sonas pli forte aŭ pli precize. Elektu la subtenatan politikon por la tuta konekto, kaj traktu la malnovajn nomojn kiel registron de tio, kiel biblioteko iam prezentis sin.