În primul rând o notă despre terminologie: securitatea semantică este o proprietate a unui cifr; nu este o metodă sau algoritm, așa că „securitatea semantică” nu poate proteja nimic. Desigur, dacă un cifru este semantic sigur, atunci ar trebui să protejeze împotriva recuperării cheii, deoarece recuperarea cheii ar duce direct la recuperarea textului simplu. Dacă este posibilă recuperarea completă a textului simplu, atunci evident că nu este sigură din punct de vedere semantic.
Un cifru bloc este un algoritm (o primitivă) care poate fi folosit pentru a crea un cifr semantic sigur. Cifrul bloc în sine ar trebui să protejeze împotriva recuperării cheilor. Atâta timp cât nu reutilizați cheia în altă parte din schemă - și aceasta este o valoare implicită sensibilă - atunci nu trebuie să oferiți protecție suplimentară. Acesta este probabil motivul pentru care nu este menționat în mod specific.
Acum, dacă nu utilizați deloc un cifr de bloc (un cifru de flux nu poate) sau dacă utilizați direct cheia pentru a crea de ex. o etichetă de autentificare, atunci da, aveți nevoie de protecție suplimentară împotriva recuperării cheilor.
Atenție că unele scheme introduc elemente noi de date care pot acționează ca chei în schemă. Dacă acesta este cazul, constructul ar trebui, desigur, să ofere protecție împotriva recuperării acelor chei. Aceasta este de ex. cazul valorii $H$ - cheia hash-sub - în modul GCM.
Rețineți că eticheta de autentificare este calculată pe textul cifrat în modul GCM, astfel încât cifrul ar fi în continuare securizat din punct de vedere semantic, chiar dacă acea cheie este scursă, chiar dacă proprietatea de autentificare a mesajului ar fi spartă. Acest lucru poate duce în continuare la pierderea confidențialității din cauza atacurilor oracolului în text clar, dar acest lucru este în afara definiției cifrului în sine.
Cifrul ar fi considerat sigur din punct de vedere semantic, deoarece modul CTR - modul de criptare de bază al GCM - ar oferi în continuare securitate semantică.
