AES-256 și OFB răspund la întrebări diferite, și exact aici greșesc recenziile cifrurilor când le tratează ca opțiuni concurente. Unul numește un cifru pe blocuri cu o dimensiune a cheii; celălalt descrie cum un cifru pe blocuri devine un flux pentru un mesaj mai lung. Un manual pentru alegerea protecției trebuie să privească întreaga construcție, inclusiv modul în care receptorul detectează un pachet modificat.

Numiți cele patru părți ale construcției

Fiecare recenzie se reduce la patru întrebări: ce primitivă și ce dimensiune a cheii, cum sunt procesate mesajele cu ea, cum respinge receptorul o modificare neautorizată și cum gestionează protocolul intrările, cheile și durata lor de viață. O listă de nume cunoscute răspunde doar la prima. A doua și a treia sunt locul unde se află diferențele reale, iar a patra este locul unde implementările se despart în tăcere. Puneți-le în această ordine și scrieți răspunsurile.

OFB apare între modurile de confidențialitate din publicația NIST despre modurile cifrurilor pe blocuri, iar confidențialitatea este tot ce oferă. Un protocol care împerechează un mod de criptare cu un MAC separat trebuie să le compună corect, iar numele unui algoritm nu dovedește acea compunere. De aceea numele modului singur nu poate decide o implementare.

A patra întrebare este cea pe care un operator o poate verifica într-adevăr pe sistemul care rulează.

Preferați o construcție autentificată

Criptarea autentificată oferă confidențialitate și integritate împreună, iar construcțiile AEAD protejează și datele asociate de modificări fără a le cripta. Este o proprietate a protecției pachetelor și nu are legătură cu faptul că o persoană s-a autentificat cu succes.

Ghidul Ghidul Netgate pentru setările criptografice ale OpenVPN indică pentru canalul de date opțiuni AEAD, între care AES-GCM, și acesta este tipul de politică acceptată care trebuie urmat. Folosiți opțiunile acceptate de versiunea instalată și de clienții pereche, în loc să copiați o ierarhie istorică a modurilor într-o implementare nouă. Compatibilitatea veche, backend-urile criptografice și suportul pentru offload limitează ce este cu adevărat disponibil.

O construcție acceptată învinge o compunere isteață de fiecare dată.

Citiți rezultatul negociat, nu oferta

Un cifru care apare într-o listă acceptată nu spune nimic despre sesiunea curentă. Citiți protecția negociată a canalului de date la client sau la gateway, apoi comparați-o cu politica pe care voiați să o impuneți. O configurație care încă listează o opțiune veche pentru un peer vechi este o decizie de compatibilitate, nu o afirmație despre sesiunea din fața dumneavoastră.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Pe un gateway ieșirea echivalentă este asocierea de securitate sau detaliile criptografice ale conexiunii, în funcție de platformă. În ambele cazuri oferta și rezultatul sunt fapte diferite. O listă care include o opțiune veche pentru un peer vechi nu înseamnă că fiecare sesiune o folosește, iar sesiunea care o folosește este ceea ce trebuia să știți.

Înregistrați ambele fapte împreună, cu data și versiunea clientului.

Măsurați doar ce se poate compara

Debitul depinde de hardware-ul punctelor terminale, de implementare, de accelerare, de dimensiunile pachetelor și de configurația aleasă. Nici lungimea cheii, nici cuvântul OFB nu vă spun care implementare va fi mai rapidă. De aceea un benchmark de pe alt site este cel mult un indiciu despre hardware-ul pe care îl are altcineva. Numerele dumneavoastră încep la punctele terminale proprii.

Pentru o comparație autorizată, țineți constante punctele terminale, sarcina de lucru și politica cerută, și înregistrați protecția negociată plus versiunile implementării. Apoi judecați rezultatul după dacă aplicația s-a terminat, cât a pierdut și ce făceau punctele terminale, în loc să deduceți costul criptografic dintr-un singur test de viteză. Un număr produs în alte condiții este o poveste, nu o măsurătoare.

Dacă un peer vechi nu poate respecta politica, aceasta este o decizie de compatibilitate pentru proprietarul lui.

Țineți integritatea în afara tranzacției

Dezactivarea verificărilor de integritate sau acceptarea unui server neverificat nu este o optimizare de performanță și nu este o corectare de compatibilitate. Schimbă proprietatea de securitate pentru care a fost aleasă construcția. Același lucru este valabil pentru lărgirea listei de cifruri acceptate până când se conectează un peer vechi: conexiunea reușește și politica nu mai există.

Scrieți construcția acceptată și proprietarul ei în manual, astfel încât următoarea schimbare să înceapă cu o decizie, nu cu o preferință.

Ce doriți este o politică pe care ambele capete o pot impune. Disputa despre care nume este cel mai puternic este o altă conversație și de obicei se termină fără decizie.

Articole similare