Acesta ar trebui să fie un comentariu (lung), dar nu am spațiu. Este menit să explice de ce ideea de a lăsa atacatorul să aleagă implementarea de bază este prea puternică --- „trivial” rupe orice primitiv.
Pentru orice primitivă criptografică, dacă un atacator dorește să extragă o cheie $k\în \{0,1\}^n$ pentru unii $n$, si poate:
Alegeți mesaje arbitrare (cel puțin mesajele conținute în $\{0,\dots,n-1\}$) în orice primitiv este luat în considerare,
Modificați în mod arbitrar implementare al algoritmului (dar nu și comportamentul de intrare-ieșire al funcției matematice pe care algoritmul o implementează)
Are acces la orice metodă de calitate pentru a măsura timpul
este destul de simplu să modifici implementarea algoritmului pentru a scurge complet cheia secretă $n$ întrebări.
Dacă $\mathcal{O}(k, m)$ este primitivul „vechi”, definiți o primitivă „nouă” prin:
Bine m)
dacă m în {0,...,n-1} și k[m] == 1:
asteapta(T)
returnează O(k, m)
Aici, T este o constantă nespecificată care este „suficient de mare”, astfel încât atacatorul să poată măsura în mod fiabil diferența dintre luarea algoritmului $\ll T$ timp, sau $\aproximativ T$ timp pentru a executa.
$\mathcal{O}'$ în mod clar are exact același comportament de intrare-ieșire ca $\mathcal{O}$.
Exemplul de mai sus ar trebui să arate că a lăsa atacatorul să aleagă implementarea este a masiv problemă de securitate, chiar dacă se restricționează implementarea pentru a avea exact același comportament de intrare/ieșire ca și funcția dorită. Ca urmare, a fi „susceptibil din punct de vedere matematic la atacuri de sincronizare” nu este bine definit, așa cum orice algoritmul care se bazează pe date „secrete” este susceptibil la atacul de mai sus.
Totuși, aceasta nu este cu adevărat o problemă, deoarece lăsarea atacatorului să aleagă algoritmul utilizat nu este văzută ca o problemă mare în practică (singurul moment în care poate apărea cu adevărat este în cazul atacurilor de tip „comitet de standarde de backdooring”, să spunem ce s-a întâmplat cu DUEL_EC_DRBG , dar ușile din spate de sincronizare par mai proaste decât ușile din spate „Cunosc o cheie secretă”, deoarece poate fi mai ușor pentru alții să observe ușile din spate de sincronizare).
Deși a fi „susceptibil la atacuri de sincronizare” nu este bine definit, există primitive care sunt mai greu de implementat într-un mod în timp constant. Acest lucru înseamnă, în general, unul dintre cele două lucruri:
- Suprafața în transformarea de la timp non-constant la timp constant este mare
- Este ușor să faci greșeli în transformarea din timp non-constant în timp constant.
Acestea nu sunt însă proprietăți formale ale problemelor, ci sunt observații empirice ale practicienilor.
Prima problemă ar putea fi formalizată (în special, într-un decalaj mare între circuitul de dimensiune minimă care calculează ceva și TM-ul de dimensiune minimă din modelul RAM care calculează ceva), dar în mod normal nu văd că oamenii încearcă să facă asta (nu pare că ar fi interesant pentru implementatori).
