M-am zgâriat de ceva vreme de ce TLS 1.3 nu include niciun mod de criptare-apoi-MAC (EtM). Toate problemele anterioare în TLS au fost cauzate de MAC apoi și de criptare. În timp ce criptați, MAC evită toate problemele cauzate de umplutură în trecut, deoarece un receptor poate verifica integritatea mesajului fără a fi nevoit mai întâi să decripteze mesajul și apoi să gestioneze corect umplutura deteriorată.
Ceea ce este enervant pentru mine este că există destul de multe micro-controlere care au accelerare hardware AES încorporată. Cu toate acestea, ceva de genul o multiplicare fără transport pentru GCM există într-adevăr doar pe procesoarele server și desktop.
În timp ce ChaCha20-Poly1305 îl folosește, înseamnă că renunțați la utilizarea hardware-ului AES pe micro-controlere. În timp ce ChaCha20 funcționează bine cu micro-urile pe 32 de biți, va folosi totuși mai multă putere decât hardware-ul AES încorporat și probabil va fi mai lent în funcție de micro. De asemenea, Poly1305 necesită efectuarea unor aritmetici modulare cu numere mari în comparație cu o mulțime de funcții hash.
Mă scarpin în cap, deoarece nu este nimic în neregulă cu EtM. Am găsit chiar și un proiect de IETF AES-CBC-HMAC unde se efectuează EtM.Cu toate acestea, nu a trecut niciodată de un draft care mi se pare ciudat.
Editați | ×:
Din moment ce au fost menționate suitele CCM Cipher. în timp ce rulați AES în modul CTR evită umplerea oracolelor. Nu face parte din pachetul de cifrat obligatoriu sau unul dintre AR TREBUI SĂ implementează suite. Vedea: Obligatoriu de implementat Cipher Suites Deci, practic, nu se poate profita de hardware-ul AES pe un micro fără a avea și GCM. (de exemplu, multe servere dezactivează CCM în mod implicit și nici Firefox, nici Chrome nu activează CCM). Deci, din nou, încă pare ciudat, nu există nimic între ele aici și nu văd cu adevărat niciun motiv bun pentru care, iar un mod EtM pare un candidat decent, dar unul nu a fost nici măcar adăugat la standard.
