De ce o cheie Blowfish mai lungă nu repară un bloc de 64 de biți

Un profil VPN oferă Blowfish cu o cheie de 448 de biți, iar cineva propune folosirea celei mai lungi chei ca să păstreze cifrul. Lungimea cheii este reală, dar este numărul greșit de optimizat. Blowfish transformă blocuri de 64 de biți indiferent de lungimea cheii, iar lățimea blocului este cea care limitează cât trafic poate proteja în siguranță o cheie. Rulați verificările de mai jos în ordine și opriți-vă la prima care scutește serviciul, pentru că un pas ulterior nu poate repara unul anterior.

Verificați ce negociază de fapt perechile

Citiți cifrul canalului de date de la ambele capete, nu din profilul pe care intenționați să îl implementați. O configurație de client poate lista mai multe cifruri, iar cel ales este rezultatul negocierii dintre două implementări și versiunile lor. Creșteți verbositatea jurnalului pe o conexiune de test și citiți linia canalului de date, care numește cifrul și dimensiunea cheii inițializate efectiv.

Dacă cifrul negociat este AES-GCM sau ChaCha20-Poly1305, opriți-vă aici. Aceste construcții folosesc un bloc de 128 de biți și autentifică sarcina utilă, deci argumentul despre coliziuni la 64 de biți de mai jos nu li se aplică.

Separați lungimea cheii de lățimea blocului

Blowfish acceptă chei de la 32 la 448 de biți, iar documentația autorului algoritmului consemnează ambele numere separat. Cheia este secretul; blocul este unitatea de transformare. Un secret mai lung face ghicitul mai greu și nu schimbă nimic la lățimea blocului pe care îl procesează cifrul.

În modul CBC, cifrul se aplică pe blocuri de lățime fixă, înlănțuite cu blocul de text cifrat anterior și completate la final. Pentru Blowfish, această lățime este de 64 de biți, adică opt octeți. Programul de chei poate fi oricât de mare doriți; lanțul avansează totuși câte opt octeți o dată.

De aceea o cheie mai lungă nu este o măsură de atenuare. Ea vizează forța brută împotriva cheii, în timp ce riscul de coliziune de mai jos este o proprietate a lățimii blocului și a modului.

Aplicați aritmetica aniversărilor la dimensiunea blocului

Un bloc de 64 de biți are o scară a aniversărilor de aproximativ 2^32 de blocuri cifrate sub o singură cheie înainte ca coliziunile să devină probabile. Fiecare bloc poartă opt octeți, deci aceeași scară înseamnă aproximativ 2^35 de octeți, sau 32 GiB de date sub o singură cheie.

Tratați-o ca pe o scară, nu ca pe o cotă. Coliziunile sunt probabilistice, iar dacă una divulgă ceva depinde de mod, de modelul de trafic și de capacitatea atacatorului de a recunoaște sau influența textul clar din jur. Primul octet dincolo de 32 GiB nu este un eveniment de descifrare, iar primii 32 GiB nu sunt certificați ca siguri.

Cercetătorii Sweet32 au demonstrat în 2016 atacuri practice împotriva cifrurilor pe blocuri de 64 de biți, inclusiv un scenariu OpenVPN, în condiții care necesitau observare și generare de trafic. Valorile implicite și versiunile de software publicate sunt context istoric, nu o descriere a implementării dumneavoastră.

Decideți dacă reutilizarea CBC contează aici

În CBC, un bloc de text cifrat repetat înseamnă că cele două blocuri de text clar diferă printr-o relație cunoscută, pentru că XOR-ul de înlănțuire se anulează. Un atacator care poate observa textul cifrat și cunoaște sau poate influența unul dintre textele clare poate recupera informații despre celălalt. Cheia Blowfish nu este niciodată necesară pentru asta.

Așadar, întrebările relevante sunt cât timp rămâne o cheie în serviciu, cât trafic trece sub ea și dacă cineva poate observa și dirija acel trafic. Reînnoirea cheilor reduce numărul de blocuri pe cheie, dar un interval de timp nu este o limită în octeți: un tunel aglomerat poate muta mult mai multe date decât unul inactiv în aceeași oră. Dacă păstrați un cifru moștenit, deduceți limita din construcție și din volumul real, nu dintr-un număr rotund.

Dacă volumul măsurat pe cheie rămâne mult sub scara aniversărilor, expunerea este mai mică. Totuși nu este zero și rămâne un motiv să planificați o migrare în loc să nu vă mai faceți griji.

Înlocuiți cifrul, nu cheia

Mutați serviciul pe un cifru AEAD acceptat și confirmați că ambele perechi, versiunile lor și backend-urile lor criptografice îl pot negocia. O cheie Blowfish mai lungă nu schimbă nimic important, iar ghicirea unei noi directive pe un singur client este felul în care un tunel funcțional devine stricat. Testați schimbarea pe un client și un server înainte de a atinge restul flotei. Păstrați profilul vechi disponibil pentru revenire până când noul cifru trece de un ciclu complet de conexiune.

Păstrați verificarea certificatelor și autentificarea conturilor în timpul schimbării. Ele răspund la întrebări diferite: o autentificare reușită nu poate lărgi un bloc, iar un cifru de date mai bun nu scuză încrederea în serverul greșit.

Încheiați verificarea citind din nou cifrul negociat pe o conexiune nouă și confirmând apoi că cifrul vechi nu mai este acceptat. Dacă o pereche îl mai oferă, migrarea nu s-a terminat, orice ar spune profilul de cealaltă parte.