Pe lângă atacurile de coliziune și preimagine, există și problema atacurilor de extensie de lungime (pe care le consider motivul „real” pentru această proprietate a SHA3).
Dacă aveți o funcție hash $H$ atunci este tentant să tratezi $H(k,m)$ ca un MAC al $m$, cu cheie secretă $k$.
Din păcate, acest lucru nu duce la un MAC sigur dacă utilizați generația anterioară (SHA1, SHA2) de funcții hash.
Atacurile de extensie de lungime au loc tocmai pentru că funcția hash îi emite întreaga stare internă.
Ideea din spatele atacurilor de extensie de lungime este următoarea:
dacă $m$ este un prefix al $m'$ apoi ieșirea $H(k,m)$ apare ca stare internă la calcul $H(k,m')$.
De fapt, din moment ce $H(k,m)$ este întreg stare internă la un moment dat, apoi puteți calcula $H(k,m')$ daca stii $H(k,m)$ -- chiar dacă nu știi $k$!
Acest lucru încalcă proprietatea de securitate pe care ați dori-o de la un MAC (învățarea MAC-ului de $m$ nu ar trebui să vă ajute să preziceți MAC-ul diferit $m'$, chiar dacă $m$ este un prefix al $m'$).
(Aici trec peste problemele de umplutură în lungime, care nu reprezintă o barieră semnificativă în calea tipului de atac pe care îl schițez.)
În timpul competiției SHA3, majoritatea trimiterilor au fost concepute pentru a fi rezistente la atacurile de extindere a lungimii.
Modul de a face acest lucru este cu așa-numita construcție „țeavă largă”: pur și simplu faceți starea internă mai mare decât ieșirea.
Cu alte cuvinte, hash-ul ar trebui să scoată doar o parte din starea sa internă la sfârșitul calculului.
Dacă faci asta, atunci $H(k,m)$ nu va conține tot ce este necesar pentru a calcula $H(k,m')$, iar acest lucru împiedică atacul de extindere a lungimii.
