Să luăm în considerare un cifru bloc în modul CTR. Și să considerăm un PRNG cu cheie sau doar un PRNG bun cu o sămânță ca cheie. PRNG-ul trebuie să fie foarte rapid.
Este o idee bună să puneți deoparte programarea cheilor și să faceți o programare „infinită” a cheilor prin generarea unui flux de chei? Apoi fiecare bloc din cifru va fi criptat cu o cheie diferită.
Desigur, chiar și un PRNG rapid are nevoie de ceva timp pentru a genera câteva 128
- chei de biți pentru un cifr. Dar nu crește acest lucru foarte mult securitatea unui astfel de algoritm? Dacă algoritmul în sine este o primitivă foarte rapidă (să zicem, la fel de rapid ca Chacha20), ar trebui să aibă o securitate excelentă și o viteză bună dacă este asociat cu un „flux de program cheie” ca acesta.
Cu toate acestea, bănuiesc că viteza unei astfel de soluții poate fi un obstacol semnificativ. Bine, deci să facem o schimbare de fiecare dată când algoritmul este repetat (criptare unică) - răsturnând doar un bit de cheie pe rundă. Dacă algoritmul necesită o cheie pe rundă și are zece runde, avem nevoie doar de zece biți. PRNG va genera astfel de biți foarte repede. Apoi cheile sunt schimbate după fiecare criptare, nu mult (schimbăm doar un bit în fiecare cheie), dar ar trebui să fie un obstacol imens pentru atacator.
Poate că am putea folosi ceva simplu, cum ar fi două runde de AES, dar nu adăugam alte două runde la cifr. Deci, să folosim acest lucru pentru a genera un flux de chei care să se amestece cu cheile într-o nouă criptare.
Întrebarea mea este despre dezavantajele unei astfel de soluții. Din câte știu eu, nu este folosit - de ce? Cu alte cuvinte, de ce folosim constante și aceleași chei în runde (când criptăm un număr mare de mesaje) când cheile pot fi modificate la un cost redus după fiecare criptare; de exemplu, prin adăugarea unui bit mod 2 (după o altă criptare, adăugăm un alt bit pe o poziție mai înaltă și așa mai departe, schimbând toate cheile de 128 de biți după 128 de criptări).
