- Poate un ascultător pasiv să rupă această criptare și/sau să creeze mesaje legitime?
Un ascultător pasiv nu ar trebui să poată inversa AES, așa că obținerea textului simplu ar trebui să fie imposibilă, cu excepția cazului în care fiecare sesiune este repornită.Cu toate acestea, această schemă ar fi vulnerabilă la atacurile oracle cu text clar. Citește mai departe.
Cât despre crearea de mesaje legitime: acesta nu este un atac pasiv.
- Acesta oferă și autentificare, deoarece nimeni, cu excepția deținătorului cheii, nu poate crea un astfel de mesaj?
Nu. Dacă înfăptuiți un om în mijloc, puteți schimba fiecare fragment din mesaj și puteți lăsa magia intactă. În modul CTR, toți biții de text simplu/ciphertext sunt independenți unul de celălalt. De asemenea, permite unui atacator să efectueze atacuri oracle cu text clar (prin schimbarea unui pic de text simplu și apoi să detecteze modul în care sistemul răspunde la acesta).
- Este OK să folosești IV/nonce cu 0 înaintea contorului? Ar trebui să atașez contorul la un număr aleatoriu (care este, de asemenea, ars din fabrică)?
Atâta timp cât contorul nu se repetă niciodată, modul CTR este relativ sigur - atâta timp cât este utilizat corect, ceea ce nu este cazul aici.
- Ce să pun la umplutură, 0 sau numere aleatorii? Este chiar necesar?
Nu, pentru modul CTR nu este necesară umplerea.
- Este logic utilizarea numărului magic în acest fel? Trebuie să generez magie aleatoare și să o trimit atât necriptată, cât și criptată pentru validare de către receptor?
În mod normal, ați folosi un mod autentificat pentru a crea o etichetă de autentificare. 32 de biți este de obicei prea mic, dar, în funcție de cazul de utilizare, ar putea fi suficient pentru sisteme în timp real etc.
- Care este metoda corectă/ bine stabilită pentru criptare și autentificare într-o astfel de setare?
Dacă aveți doar AES, atunci modul CCM ar fi modul normal.
NB
Schema pe care o descrieți în prezent pare mai potrivită pentru criptarea directă AES sau AES-CBC. De exemplu, dacă ați tampona și criptați contorul, l-ați putea folosi ca IV pentru AES-CBC. Dacă ai pune valoarea 02 în octeții de umplutură ai mesajului, atunci veți avea padding compatibil PKCS#7. Avantajul acestui lucru este că biții din criptarea blocului AES a mesajului sunt acum toți dependenți unul de celălalt, prin urmare magia ar funcționa ceva mai bine.
Schema dvs. actuală pare să fie limitată la o singură sesiune.În mod normal, veți obține chei de sesiune noi pentru fiecare sesiune.
Chiar dacă modul este schimbat la CBC, există un $1 \peste 2^{32}$ șansa ca un atacator să creeze un mesaj cu o magie validă, doar încercând la întâmplare. Restul mesajului ar fi probabil deranjat, dar nici procesarea textului denaturat ar putea să nu fie o idee bună. Poate că ar putea fi implementate contramăsuri suplimentare împotriva acestui lucru (cu toate acestea, majoritatea acestora ar putea duce la atacuri DoS).
