Puncte:3

Utilizarea corectă a AES CTR

drapel cn

Am citit că AES CTR este sigur numai dacă este utilizat corect. Prin urmare, vreau să fiu sigur că îl folosesc corect.

  1. Vectorul inițial (IV) poate fi folosit o singură dată, nu trebuie să fie aleatoriu. Este sigur să folosiți un contor pentru o parte a IV-ului, cealaltă parte este doar un text const. Contorul este transmis tuturor în text clar, în timp ce partea sensibilă a mesajului este criptată. Este o problemă că următorul IV este previzibil?
  2. Î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?
  3. Nu în ultimul rând, crește securitatea utilizarea AES-256 peste AES-128 pentru a cripta un mesaj de 16 octeți?
Puncte:2
drapel in

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).


Gilles 'SO- stop being evil' avatar
drapel cn
Nu! Pentru CTR, nu este suficient ca IV să nu se repete. **Valoarea contorului** nu trebuie să se repete.
kelalaka avatar
drapel in
@Gilles'SO-stopbeingevil' nu mai fi porecla ta. În primul rând, vorbim de 16 octeți, în al doilea rând am spus „Garantează că contorul nu trece niciodată de toate cele 1 stări”. Unde se spune ca continua o contravaloare?
Maarten Bodewes avatar
drapel in
Pot vedea cum se utilizează termenul IV pentru Nonce + counter, deoarece IV este folosit doar ca valoare inițială - este vectorul de inițializare până la urmă. Așa cum este definit, cei 16 octeți sunt denumiți mai bine *bloc contor*, constând din nonce + contor.@Gilles'SO-stopbeingevil' Dacă respectați definițiile NIST, nici repetarea contorului nu este suficientă, deoarece aceasta este doar o parte a blocului de intrare/contor, deci da, terminologie.
Gilles 'SO- stop being evil' avatar
drapel cn
@MaartenBodewes Dacă împărțiți blocul de contor într-un nonce per mesaj și o valoare de contor per bloc, atunci cerința devine ca nonce per-mesaj să nu se repete și ca valoarea contorului per bloc să nu depășească. Nu toate prezentările modului CTR fac asta. Acest răspuns definește în mod explicit âIVâ ca bloc inițial complet constând din nonce concatenat cu un contor și nu este suficient ca _that_ să fie unic: partea nonce trebuie să fie unică. Repetarea nonce cu valori inițiale diferite de contor nu este suficientă.
kelalaka avatar
drapel in
@Gilles'SO-stopbeingevil' ideea este că sunt bine conștient de această problemă și pentru 16 octeți nu a fost o problemă. Nu am spus niciodată să continui o valoare de contor sau să folosești o altă valoare de contor. Contorul începe de la 0, continuarea către un contor este o cale periculoasă și nu o bună perspectivă de securitate care crește numărul de capcane. Acum, am făcut o distincție între partea contor și contra parte a IV-ului.
Gilles 'SO- stop being evil' avatar
drapel cn
În cazul foarte specific în care toate mesajele au (cel mult) un bloc, atunci da, IV și valoarea contorului sunt aceleași. Dar acesta este un caz foarte special la care întrebarea nu este limitată în mod clar (apare doar într-o singură subîntrebare). Răspunsul tău este acum corect din punct de vedere matematic strict, dar este totuși foarte înșelător, deoarece faptul că este specific pentru cazul mesajelor cu un singur bloc, care este un scenariu foarte neobișnuit, abia se vede.
kelalaka avatar
drapel in
@Gilles'SO-stopbeingevil' Am dat cazul general în contractul de securitate. Nu-mi place ideea de continuitate a contorului. Ei bine, în unele medii de constrângere, oamenii au nevoie de asta pentru a schimba mai puține chei. Totuși, nu le consider aici. Începeți contorul de la 0. Verificați textul din nou și din nou pentru a nu induce în eroare...
Gilles 'SO- stop being evil' avatar
drapel cn
Nu, în cazul general, cu blocul contor structurat ca nonce||contraparte (ceea ce nu toate prezentările și implementările CTR fac), obligația este ca nonceul să nu se repete.Și datorită dimensiunii limitate pentru nonce, acest lucru necesită practic să ținem evidența nonce-urilor utilizate anterior, ceea ce nu este întotdeauna realizabil. Este o capcană a CTR pe care utilizatorii tind să o greșească, iar răspunsul dvs. i-a încurajat să greșească.
kelalaka avatar
drapel in
@Gilles'SO-stopbeingevil' Este posibil ca cineva să poată combina aleatoriu și container pentru a forma nonce, deși acest lucru necesită calcul și asta necesită durata de viață a cheii și numărul de mesaje per cheie. După cum am spus, dacă există o problemă, schimbați o cheie nouă. Sfatul meu general este să utilizați xChaCha, deoarece are un interval nonce mai bun. După cum a spus Lindell odată, blocul de 256 de biți este necesar pentru a putea avea limite CTR și GCM mai bune. Nu cred că îi duc la capcană, deja i-am restricționat să nu cadă într-una.
drapel au
De asemenea, de menționat, rețineți că (pe design) CTR utilizează același algoritm pentru criptare și decriptare. Acest lucru ar putea duce la decriptare neautorizată în anumite contexte (deși pentru aceasta necesită repetarea unui IV).
Puncte:1
drapel cn

Pentru CTR, cerința este ca contravaloare nu se repetă (pentru o anumită cheie). Cea mai mare problemă cu modul counter este că nu este suficient pentru IV (cel iniţială valoarea contorului) a nu repeta.

Nu contează dacă valoarea contorului este previzibilă. Dacă puteți aranja ca contorul să înceapă de la 0 și să crească cu 1 pentru fiecare bloc de mesaje, acesta este o modalitate foarte bună de a utiliza CTR. Rețineți că în cazul mai multor mesaje, aceasta înseamnă că primul mesaj folosește valorile contorului $0, 1, 2, \ldots, a$, apoi al doilea mesaj folosește valori de contor $a+1, a+2, \ldots, b$, al treilea mesaj folosește $b+1, b+2, \ldots, c$, și așa mai departe.

Permiteți-mi să ilustrez ce nu merge bine cu o valoare de contor care se repetă. Lăsa $E$ fie funcția de criptare bloc și scrie $\langle n\rangle$ pentru codificarea unei valori de contor $n$ ca un bloc. Dacă trimiteți două mesaje în două blocuri $P_0||P_1$ și $P'_0||P'_1$ (unde fiecare $P^{(j)}_i$ reprezintă un bloc), unul cu IV $n$ iar următorul cu IV $n+1$, atunci textele cifrate respective sunt $C_0||C_1 = (E(\langle n\rangle) \oplus P_0) || (E(\langle n+1\rangle) \oplus P_1)$ și $C'_0||C'_1 = (E(\langle n+1\rangle) \oplus P'_0) || (E(\langle n+2\rangle) \oplus P_1)$. Observați modul în care sunt folosite ambele texte cifrate $E(\langle n+1\rangle)$. Un adversar poate xor cele două blocuri de text cifrat care folosesc aceeași valoare de contor, iar masca lor de criptare se anulează: $C_1 \oplus C'_0 = P_1 \oplus P'_0$. Acest lucru este adesea suficient pentru a ghici unele sau toate blocurile de text simplu. De exemplu, multe mesaje conțin un antet cunoscut sau cel mai adesea cunoscut, iar în acest exemplu de repetare a valorii contorului, aceasta se transformă în dezvăluirea conținutului a ceea ce este de 16 octeți după antetul din primul mesaj.

Dacă nu puteți ține evidența valorilor de contor au fost utilizate, o tehnică comună pentru a evita repetarea este să utilizați o aleatorie de 16 octeți pentru IV. Acest lucru face șansa de a reutiliza o valoare a contorului suficient de mică încât să nu se întâmple în practică.

În cele mai multe cazuri, ar trebui să utilizați un standard criptare autentificată (AEAD) în schimb, de exemplu SIV sau sau GCM-SIV sau GCM sau CCM. Acest lucru are două beneficii. Una este că textele cifrate sunt autentificate: la decriptare, puteți verifica dacă textul cifrat nu a fost modificat. (Este imposibil să se verifice autenticitatea unui text cifrat fără cheia secretă. Un adversar poate încă schimba două mesaje autentice, deci autenticitatea nu implică chiar integritate.) Celălalt avantaj al utilizării unui mod AEAD standard este că este suficient pentru securitate ca valoarea contorului nu se repetă: nu există alte condiții subtile. Modurile SIV au avantajul că, chiar dacă IV-ul se repetă accidental, acest lucru poate dezvălui doar că mesajele sunt identice, nu va dezvălui nimic despre conținutul lor.

Folosirea AES-256 mai degrabă decât AES-128 îmbunătățește doar securitatea împotriva computerelor cuantice, în cazul în care acestea devin practice.

kelalaka avatar
drapel in
Vorbim de 16 octeți!
Maarten Bodewes avatar
drapel in
Randomizarea completă a IV-ului poate face ca contorul să se repete mai devreme, deși diferența este relativ mică - implementările efectuează de obicei o creștere de $2^{128}$ a întregului bloc, deci dacă o parte a contorului este mare și una dintre următoarele nonce în secvența este scăzută, atunci ați avea o coliziune înainte de a utiliza toate valorile posibile ale contorului. Separarea nonce și contor este probabil cea mai bună modalitate de a proceda, unde contorul inițial poate fi inițializat la zero.
Gilles 'SO- stop being evil' avatar
drapel cn
@MaartenBodewes „Radomizarea completă a IV-ului poate face ca contorul să se repete mai devreme”, ceea ce nu poate fi corect. De exemplu, dacă luați cazul extrem al unei împărțiri de 1/127 de biți între nonce per mesaj și contor per bloc, aceasta garantează o repetare a valorilor contorului cel mult pe cel de-al treilea mesaj.
Maarten Bodewes avatar
drapel in
Să presupunem că aveți o dimensiune maximă a mesajului de 2^32 de blocuri. Apoi folosiți cei 96 de biți rămași ca nonce (aleatoriu), iar dacă utilizați un numărător de 32 de biți pentru a rămâne în nonce; în acest fel, creșterea contorului nu poate crea o coliziune cu un bloc de contor cu un nonce diferit.Acest lucru se poate întâmpla totuși dacă randomizați complet blocul de contor, deoarece distanța dintre contoarele a două nonces ulterioare variază. Desigur, nu este vorba de momentul în care este garantată repetarea, ci de când este posibilă sau probabilă.
Gilles 'SO- stop being evil' avatar
drapel cn
@MaartenBodewes Aceasta presupune că puteți urmări ce non-uri au fost folosite anterior. Am recomandat să utilizați un IV aleatoriu (care ocupă blocul complet) doar pentru cazul în care _nu puteți_ urmări ce nonces au fost folosite, așa că cel mai bine puteți este ca valoarea nerepetată să fie unică din punct de vedere statistic. Există un scenariu în care nonce determinist + contor per mesaj este mai bun, adică atunci când puteți ține evidența numerelor de secvență a mesajelor, dar nu cunoașteți lungimea mesajului în avans. Acest lucru este oarecum comun în protocoalele de comunicare. Dar este puțin prea în afara scopului pentru răspunsul meu aici.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.