Dacă există deja mijloace de autentificare a textului simplu, atunci este într-adevăr posibil să omiteți autentificarea textului simplu sau a textului cifrat prin alte mijloace.
Există, desigur, niște catcha.
În primul rând, textul simplu nu ar trebui să fie folosit în niciun fel înainte ca valoarea hash autentificată să fie verificată.Dacă nu este cazul, atacatorul poate schimba textul simplu, ceea ce înseamnă că partea este supusă mai multor tipuri de atacuri, inclusiv oracolul textului simplu sau eventual injecția de greșeală.
În plus, implementarea nu ar trebui să ofere nicio informație despre procesul de decriptare. Dacă o face, atunci implementarea poate deveni supusă atacurilor pe canale laterale. Mai rău, dacă de ex. CBC este folosit, apoi se aplică oracole de umplutură. Prin urmare, este mai logic să folosiți AES-CTR sau un cifr de flux, cum ar fi ChaCha20.
Ultimele două greșeli de proiectare/implementare pot fi evitate atunci când se utilizează un mod autentificat. Așadar, modul autentificat poate fi folosit chiar dacă cheia nu poate fi de încredere. Un dezavantaj este că alți dezvoltatori ar putea presupune că modul autentificat oferă autentificarea necesară și să înceapă să folosească textul simplu chiar dacă mesajele nu au fost încă autentificate.
Personal, nu aș folosi modul autentificat pentru asta.
Rețineți că manipularea IV nu este specificată în protocolul pe care îl descrieți. Nu este necesar să facă parte din hash dacă asta protejează mai degrabă textul simplu decât textul cifrat. Cu toate acestea, ar trebui să vă asigurați că este unic pentru fiecare mesaj care este criptat cu aceeași cheie (și dacă utilizați modul CBC, imprevizibil).
De asemenea, nu văd dacă protocolul este susceptibil la atacuri de reluare și atacuri de ghicire în text simplu, dacă hash-ul autentificat este folosit atât pentru identificare, cât și pentru autentificare.
