CFB1 versus CFB8 versus CFB128: este dimensiunea feedback-ului, nu a cheii

Un nume precum AES-256-CFB1 poartă două numere, iar ele răspund la întrebări diferite. 256 este lungimea cheii AES. 1 este feedback-ul CFB, adică dimensiunea segmentului, o proprietate a modului în care modul își avansează starea. Citit ca lungime de cheie, 1 face numele să pară o configurare greșită catastrofală, și de aceea întrebarea revine mereu.

Decideți care dintre trei mărimi o priviți înainte de a judeca numele: dimensiunea cheii, dimensiunea blocului sau dimensiunea segmentului. Doar prima este un parametru de securitate în sensul obișnuit.

Trei numere, trei mărimi

AES acceptă chei de 128, 192 sau 256 de biți și are un bloc de 128 de biți, orice ați alege. Dimensiunea blocului aparține AES, nu modului. Sufixul CFB este a treia mărime: cât de multe date consumă și returnează modul la fiecare pas. Documentația AES a OpenSSL enumeră explicit acele dimensiuni de deplasare pentru variantele CFB.

CFB1 returnează un bit o dată, CFB8 un octet, CFB128 un bloc întreg. Toate trei folosesc intern același cifru de bloc de 128 de biți; ceea ce se schimbă este câți biți din fiecare bloc calculat sunt folosiți per operație. De aceea sufixul mută costul și comportamentul de bufferizare, nu puterea cheii.

De ce dimensiunea blocului nu se schimbă niciodată

AES este un cifru de bloc cu un bloc fix de 128 de biți, iar modurile sunt construcții clădite în jurul lui. Niciunul nu micșorează blocul ca să se potrivească dimensiunii segmentului. O implementare CFB1 calculează în continuare un bloc AES complet și ia un bit din rezultat. Ceilalți biți sunt aruncați pentru acel pas, și exact acolo stă costul de eficiență.

Deci un feedback de un bit nu implică o cheie de un bit, iar un nume nu poate fi ierarhizat după sufix. CFB128 nu este de patru ori mai puternic decât CFB32; procesează segmente mai mari.

Ce schimbă de fapt dimensiunea segmentului

Dimensiunea segmentului schimbă cât text cifrat este returnat la fiecare pas și cât text clar poate duce fiecare pas. Schimbă și propagarea erorilor și comportamentul de bufferizare, ceea ce contează pentru utilizarea de tip flux. Segmentele orientate pe octeți se aliniază cu bufferele, cele orientate pe biți nu.

În practică protocolul alege modul, nu operatorul. Un canal de date VPN folosește construcția specificată de protocolul său, cu propria protecție de integritate, iar o listă de bibliotecă spune doar ce nume există.

Cum citim o etichetă CFB necalfificată

O etichetă CFB necalfificată are nevoie de contextul implementării. În antetele OpenSSL 1.0.2, EVP_aes_128_cfb este o macrocomandă pentru EVP_aes_128_cfb128, cu aliasuri corespunzătoare pentru chei de 192 și 256 de biți. Aceasta este o convenție de denumire API dintr-o singură ramură, nu o afirmație că fiecare bibliotecă, format de fișier sau GUI extinde abrevierea la fel. Verificați antetul sau documentația versiunii din fața dumneavoastră.

Dacă un profil vechi spune CFB și partenerul îl acceptă, parametrii negociați sunt înregistrați undeva: într-un jurnal, într-un dump de configurare, într-un răspuns API. Citiți-le în loc să deduceți dimensiunea segmentului dintr-un șir afișat.

Ce nu vă spune numele unui mod

Numele descrie comportamentul de criptare și nimic altceva. Un VPN are în continuare nevoie de protecție a integrității, derivarea cheilor și autentificarea partenerului, iar CFB nu oferă niciuna. Nici înlocuirea CFB8 cu CFB1 nu este o schimbare cosmetică: comportamentul pe fir diferă și ambele părți trebuie să sprijine aceeași construcție. Nici un nume dintr-o bibliotecă nu dovedește că gateway-ul implementat îl acceptă pentru canalul său de date.

Pentru orice este întreținut, folosiți aranjamentul complet de protecție al protocolului și politica operatorului, și înregistrați versiunile bibliotecii și ale gateway-ului, opțiunea exactă și rezultatul negociat. Numele vechi explică ce citiți; nu justifică reînvierea configurației.