Scenariul
Folosind AES 256 cu modul CBC. (Autentificarea se face separat. Ignorat aici.)
Scopul (explicat mai mult mai târziu)
Pentru a evita trimiterea unui IV necriptat.
Dar, deoarece acest lucru se face folosind .NET a cărui funcție ne obligă să folosim un IV, nu putem doar să punem înaintea 16 octeți aleatori și apoi să aruncăm primii 16 octeți după decriptare.
Planul
Adăugați 16 octeți aleatori ("IV1"), și, în plus, utilizați 16 octeți cu valoarea zero ca IV ("IV0"). Apoi trimiteți textul cifrat fără primii 16 octeți.
Decriptarea se va face de către receptor, determinând mai întâi care este primul bloc text cifrat va fi (pentru acea cheie AES, pentru orice mesaj) prin criptarea a ceva în modul menționat mai sus (ceea ce va trebui făcut o singură dată pe cheie) și luând primii 16 octeți ai textului cifrat rezultat.
Apoi predau acești octeți textului cifrat decupat primit pentru a obține textul cifrat original nedecupat și apoi îl decriptează cu un IV ("IV0") de 16 octeți de valoare zero (adică folosesc funcția de decriptare a .NET, alimentându-i cu IV-ul necesar, care sunt acele 16 zerouri).
Apoi renunță la primii 16 octeți ai rezultatului (care sunt primiți de la .NET după ce .NET renunță la primii 16 octeți care sunt IV), deoarece aceștia sunt cei 16 octeți aleatori predați ("IV1").
Dar de ce?
Comunicarea IV-ului în text clar oferă un atacator cu forță brută un avantaj - ei pot decripta doar un bloc (16 octeți) și îl pot compara cu IV-ul pentru a verifica dacă cheia este corectă. (Poate că există mai multe canale de atac posibile de care nu știu.)
Deci întrebarea mea este
Acest plan pare în regulă sau există vreo capcană în el?