Cât de nesigur ar fi un cifru bazat pe hashing iterativ?

Mă întrebam cum ar putea fi nesigură următoarea construcție. Pot spune că sunt posibile atacuri cunoscute, dar nu sunt sigur de nimic altceva.

Lăsați utilizatorul să aleagă o parolă și să o trimită de un număr suficient de mare de ori cu ceva cu rezistență înainte de imagine, cum ar fi SHA-256. XOR textul simplu cu hash. Hash-ul din nou. XOR rezultatul cu următorul bloc de text simplu... și așa mai departe până la sfârșit. Cum ar putea adversarii să încalce asta?

TL;DR; Nesigur, nu-l folosi. Utilizați standardele și modul de operare bine-cunoscut.

Construcția ta este $s_i = H^i(parolă)$ adică hash parola $i$ ori apoi utilizați ieșirile $s_i$ pentru fiecare pas la x-sau cu textul simplu pentru a ajunge la textul cifrat; $c_i = p_i \oplus s_i$

Cum ar putea adversarii să încalce asta?

Există modalități de a realiza acest lucru

• Atacul ghicitului: Dacă cineva primește o parte din mesajul tău, cum ar fi cel puțin 256 de biți dintr-un bloc complet SHA-256, atunci restul mesajelor sunt decriptate cu ușurință. Asa de aici nu există secret..

  Ar trebui să se uite la aceste diapozitive despre Hash_DRGB vezi un design mai bun împotriva compromisurilor de stat. Când se produce o secvență pseudo-aleatoare, compromiterea stării curente nu trebuie să scurgă alte stări. Principalul eșec al designului propus este acesta.

• Schema ta pare a fi vulnerabilă atacul interzis că atunci când $(IV,cheie)$ Perechea reluarea modului CTR poate rupe confidențialitatea textului cifrat. Nu definiți un IV în schema dvs., așa că veți avea aceeași parolă, iar fluxul generat de cifrul dvs. va produce aceeași ieșire tot timpul.

  Oricine trebuie să schimbe parola la fiecare criptare sau trebuie să introducă practici IV standard pentru a atenua, altfel doom!

• Securitatea parolei nu poate fi verificată și folosim de obicei funcții de derivare a cheilor bazate pe parolă, cum ar fi PBKDF2, Scrypt sau Argon2, pentru a obține aleatorie din parole. Acestea, cel puțin, oferă un număr de iterații pentru a atenua atacurile de căutare prin parole. Au, de asemenea, cablaj de memorie și număr de fire pentru a reduce capacitățile atacurilor de căutare prin parole. Deoarece schema dumneavoastră este vulnerabilă la atacul interzis, va fi mai greu sau mai greu pentru un utilizator să selecteze o nouă parolă pentru fiecare criptare.

  În schimb, folosim chei aleatorii care sunt fie generate local pentru a fi utilizate, fie derivate din protocoale precum DHKE.

• Securitatea schemei dvs. depinde foarte mult de securitatea parolelor și va fi un punct de atac bun, deoarece utilizatorul general nu reușește să obțină și să gestioneze parole bune.Deși se pot folosi parole precum zarurile pentru a genera parole care au puterea de aproximativ 256 de biți, cu cât mai multă criptare, cu atât mai multă parolă de memorat va deveni imposibilă. În schimb, folosirea unei parole bune și obținerea unei chei de criptare care criptează intrările aleatorii pentru schema dvs. este un candidat mai bun.

  Pentru criptarea locală, practica obișnuită este; generând o cheie aleatoare de criptare a fișierelor FEK pentru fiecare fișier. Apoi, folosind parola utilizatorului, obțineți o cheie de criptare a cheii (KEK) cu un PBKDF bun precum Argon2. Cu KEK criptați și decriptați FEK-urile, apoi criptați/decriptați fișierele. Mai multe detalii este Aici.

• Schema ta nu are acces aleatoriu, deci nu este util pentru multe aplicații precum criptarea discului.

• Ați solicitat doar rezistență înainte de imagine, dar o veți face și necesită rezistență la coliziune. Dacă coliziunile pot apărea cu ușurință pe fluxul generat, atunci acesta se va repeta și acesta este un punct de atac. Cel puțin fluxul dvs. nu va fi o secvență pseudo-aleatorie. Din fericire pentru tine, SHA-256 are rezistență la coliziune și intervalele de cicluri așteptate sunt uriașe;

  Fie modelul SHA-256 ca o funcție aleatorie uniformă, atunci probabilitatea ca elementul să fie pe ciclu este

  $$\frac{1}{\sqrt{\hspace{,03 in}2\hspace{-0,05 in}\cdot \hspace{-0,04 in}\pi} \cdot 2^{127}}$$

  Durata medie a ciclului cu valoarea așteptată pentru SHA-256 este $$2^{127} \sqrt{2\pi}$$ Prin urmare, nu vă temeți de ciclurile scurte. Ref este Harris, 1960

• Schema dvs. nu are securitate Ind-CPA.

Ce avem în loc de asta?

• Avem binecunoscutul mod CTR care poate converti orice Funcție Pseudo-Random (PRF) într-o schemă de criptare din 1979. Este lucrarea fundamentală a lui Whitfield Diffie și Martin Hellman;

  • Confidențialitate și autentificare: o introducere în criptografie ca o lucrare invitată despre Proceedings of the IEEE, 67 (1979), pp. 397–427.

Acesta este un avantaj imens, deoarece permite utilizarea unei game largi de funcții în loc de doar PRP-uri.Modul CTR are IV pentru a randomiza criptarea și realizează criptarea probabilistică. CTR poate atinge securitatea Ind-CPA.

În prezent, toate cifrurile din modul TLS utilizează modul CTR intern, AES-GCM, AES-CCM și ChaCha20-Poly1305.

Concluzie

Nu există niciun avantaj față de modul CTR, chiar dacă adăugați IV la schema de criptare și chiar dacă rezolvați problema parolei și partea cea mai problematică: atacul ghicirii.

Înainte de a vorbi despre atacuri, vă sugerez să folosiți chei aleatorii cu destui biți (cel puțin 128 de biți) în locul parolelor. Nu este nevoie să rubricați cheia de multe ori, doar folosiți o cheie bună. Dacă este derivată din parolă, utilizați o funcție bună de derivare a cheii pentru a deriva cheia și utilizați-o în schimb.

Acum, revenind la întrebarea dvs., ați spus-o singur, un atac de text simplu cunoscut este posibil. Și este dezastruos de ușor să faci asta.Tot ce trebuie să știți este un singur bloc de text simplu pentru a recupera tot textul simplu ulterior prin dezvăluirea hash-ului din acel bloc. Acesta este un nivel de securitate mult mai scăzut în comparație cu ceea ce se așteaptă de la cifrurile moderne, care sunt concepute pentru a fi sigure împotriva adversarilor capabili să efectueze atacuri alese cu text clar sau cu text cifrat ales. Nici măcar nu este atât de dificil de înțeles sau cel puțin de a restrânge numărul fezabil de încercări pentru un bloc de text simplu pe baza formatelor de fișiere, puține informații disponibile despre proprietarul fișierului etc., care pot fi folosite pentru a decripta întregul text cifrat.

De fapt, cu mult înainte să mă gândesc și la un cifr similar, dar în loc să trimit totul în mod iterativ, m-am gândit să fac xor din jumătatea stângă a ieșirii hash cu blocul de text simplu și hash jumătatea dreaptă pentru următorul bloc. Acest lucru poate fi randomizat prin amestecarea numărului public aleatoriu cu cheia. Un alt mod mai bine cunoscut este utilizarea hash în modul CTR pentru a genera fluxul, așa cum facem cu cifrurile bloc, deoarece modul CTR nu necesită să puteți decripta blocul. După cum a subliniat kelalaka, oferă și acces aleatoriu.

Dar amintiți-vă că acest lucru nu poate fi demonstrat ca fiind sigur în modelul simplu și, prin urmare, nu puteți fi foarte sigur de securitatea sa cu funcții hash precum SHA-2, care nu a fost conceput pentru a fi utilizat în acest fel. Acest lucru necesită o presupunere suplimentară că funcția ta hash este suficient de aproape de un oracol aleatoriu pentru a fi utilizată astfel în siguranță. Și chiar dacă este sigur cu funcții hash obișnuite, probabil că nu va avea o utilizare pe scară largă, deoarece va fi mult mai lent decât AES sau Chacha20 asistat de hardware (care folosește și modul CTR așa cum s-a menționat mai sus).