Aici am făcut o distincție. $nonce \mathbin\|contraparte$ constituie $IV$
- Este o problemă că următorul IV este previzibil?
Nu, nu este o problemă în modul CTR, citiți mai multe în [1]. The $IV= (nonce\mathbin\|omologul)$ este criptat și textul cifrat este x-ored cu text simplu.
$$C_i = \operatorname{AES-CTR}(nonce\mathbin\|encode(i)) \oplus P_i$$
Atâta timp cât $(IV,cheie)$ perechea nu se repetă niciodată, nu există nicio problemă pentru cei 16-octet presupunând că începeți întotdeauna de la 0 în contor pentru fiecare criptare cu o nouă cheie nonce sau nouă.
Dacă există o repetare, atunci confidențialitatea se pierde.
Înțeleg că IV-ul nu se poate repeta niciodată, dar în cazul în care sunt necesare câte iterații ale acestei condiții pentru a sparge sistemul. Adică două repetări ale aceluiași contor sau 100?
Două perechi sunt suficiente pentru a rupe confidențialitatea cu tehnici de crib-and-dragging. Acum este automatizat [2]. Dacă îl cunoști pe unul dintre ei, atunci este banal să-l găsești pe celălalt cu x-sau.
Nu în ultimul rând, crește securitatea utilizarea AES256 peste AES128 pentru a cripta un mesaj de 16 octeți?
Modul CTR este securizat CPA atâta timp cât este utilizat corect. AES-128 este sigur (în mare parte)[3] cu toate acestea, folosind AES-256, va fi în siguranță chiar și adversarii cuantici furnizați cu Grover's Machine.
Rețineți că, cu modul CTR, puteți obține doar securitate CPA, adică nu există integritate și autentificare. Pentru a obține integritatea și autentificarea se poate folosi AES-GCM (cu SIV). Modul SIV utilizează mesajul pentru a evita problema IV.Când IV-ul se repetă, scurge doar egalitatea mesajelor, nu și conținutul.
Utilizarea corectă a AES CTR
Obligațiile dumneavoastră: ca contract de securitate
Selectați cheia uniformă aleatorie $k$ de mărimea 256 și păstrați-l secret, tot timpul.
Selectați IV și asigurați-vă că $(k,IV)$ nu se repetă niciodată chiar și contorul incrementat;
folosește o contor determinist sau LFSR pentru a ține evidența $nonce$, asigurați-vă că o nouă cheie este schimbată dacă există o eroare/oprire a sistemului, este posibil să nu poată scrie ultima cheie folosită $nonce$.
Sau, folosiți aleatoriu $nonce$, asigurați-vă că sunteți jos la ciocnirea $nonce$ sub aceeași cheie.
Porniți întotdeauna ghișeul de la $0$. Dacă contorul nu începe de la $0$ există o cale periculoasă care poate conduce IV să se repete dacă nonce este același.
Criptați mesajul și asigurați-vă că nu este mai lung de $2^{32}$.
- Garantați că nu există un deosebitor și
- Garantați că contorul nu trece niciodată de toate cele 1 stări, adică nu depășește niciodată valoarea maximă a contorului.
Păstrați-l.
Ce obții
- Securitate Ind-CPA și nimic mai mult!
În schimb, se poate folosi XChaCha20-Poly1305 cu nonces pe 192 de biți pe care $(IV,cheie)$ apariția este neglijabilă. Veți obține și autentificare și integritate. Și, deoarece modul CTR este proiectat pentru PRF, XChaCha20 este mai bine să fie utilizat cu modul CTR (XChaCha20 folosește CTR intern).