De ce sunt folosite în mare parte cifrurile bloc ca cifruri de flux?
Modul CTR nu are nevoie de umplutură, cum ar fi modul CBC, care a provocat multe atacuri de-a lungul anilor, cunoscut sub numele de atacul padding oracle [1] [2]. In cele din urma, CBC este eliminat din TLS, TLS 1.3 are doar cifruri în modul CTR (rfc 8446).
+------------------------------+-------------+
| Descriere | Valoare |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
Atacurile și decizia TLS au crescut utilizarea modului CTR. Amintiți-vă că aproape toată securitatea pe internet se bazează pe TLS. Conform sondajului SSLlabs, %46.6 dintre site-uri acceptă TLS 1.3 ( Suport protocol )
Nici modul CTR, nici CBC, nici CFB (toate modurile de arhivare a operațiunilor) nu au un MAC prin design. Pentru a avea un Mac fie folosiți HMAC, fie folosiți GCM, CCM, Poly1305 etc.
Dacă vorbim despre mod teoretic, CBC și CTR pot furniza doar Ind-CPA. Dincolo de aceasta, este nevoie de integritate pentru Ind-CCAx. Pe de altă parte, criptarea autentificată (GCM, CCM, Poly1305) oferă o securitate mai mare decât Ind-CCAx,
Acest lucru nu reduce dimensiunea efectivă a blocului algoritmului la 1 bit, deoarece un bit este mapat la un alt bit, în funcție de biții fluxului cheie?
Ei bine, dacă utilizați CBC și aplicați o umplutură, atunci executați mai multe lucruri decât eliminarea biților inutile din bloc. În ambele cazuri, numărul de blocuri criptate este aproape același (cu excepția cazului în care blocul este plin, atunci pentru PKCS#7 este nevoie de un bloc suplimentar). Apoi, aplicarea căptușelii și a depășirii sunt funcții suplimentare de aplicat. Modul CTR trebuie să x-sau fluxul.
După cum s-a menționat în comentarii, modul CTR este extrem de paralelizabil, chiar și permite accesul aleatoriu sau pre-chaching-ul fluxului. Performanțele OpenSLL de mai jos pe mașina mea
viteză openssl -evp aes-128-cbc aes-128-ctr
| tip |
16 octeți |
64 de octeți |
256 de octeți |
1024 de octeți |
8192 octeți |
16384 octeți |
| aes-128-cbc |
818912,47k |
1365115.22k |
1404590,75k |
1409671,85k |
1410523.14k |
1411497,98k |
| aes-128-ctr |
561928,57k |
1899517,87k |
3908505.17k |
5220669,78k |
5835377.32k |
5876869.80k |
După cum putem vedea, cu excepția mesajelor foarte scurte CTR a batut CBC în AES-NI.
Nu ar fi de preferat să păstrăm dimensiunea blocului unui cifr?
Nu
Trebuie să ne ocupăm de căptușeală și problemele sale de nesiguranță, de ce să nu o eliminăm deloc când avem modul CTR.
De asemenea, crește dimensiunea datelor cu maximum 16 octeți pentru AES.
Modul CTR prin proiectare folosește PRF în loc de PRP (cifrele bloc sunt PRP), aceasta oferă o gamă mai largă de funcții de utilizat - la fel cum folosim ChaCha20. În modul CBC trebuie să folosim un PRP.
Desigur, nimic nu este perfect! Fiecare mod are avantajele și dezavantajele sale. În funcție de context, se poate prefera unul altuia. În sensul comun, în criptografia modernă, preferăm modurile de criptare autentificate precum AES-GCM (probabil cu SIV) și ChaCha20-Poly1305 (mai bine xChaCha20-1305 pentru nonces pe 192 de biți).
