Imposibilitatea unei scheme securizate „blind HMAC” - un analog bazat pe HMAC al semnăturilor oarbe - este cunoscută (după cum am înțeles eu, în principal din cauza faptului că utilizatorul nu poate valida semnătura primită pe o cheie publică pentru semnatar și, prin urmare, neputând fi sigur că semnatarul nu folosește multe chei de semnătură și mai târziu le „dezvăluie” determinând care dintre cheile lor este validă pentru o anumită semnătură).
Cu toate acestea, din perspectiva performanței și a dimensiunii semnăturii/MAC, HMAC este adesea preferabil semnăturilor în care verificatorul care deține cheia simetrică a semnatarului este acceptabil.De exemplu, semnăturile BLS (oarbe sau nu) în modul de dimensiune minimă a semnăturii cu curba BLS12-381 consumă 384 de biți cu o țintă de securitate de 128 de biți - acesta este, aparent, destul de scurt după standardele de semnătură. În comparație, se pare că, de exemplu, un hash de 128 de biți poate oferi 128 de biți de securitate atunci când utilizați HMAC.
Într-o astfel de situație, ar funcționa o schemă de autentificare oarbă „semi-HMAC”? Ceva asemănător cu:
- Utilizatorul generează și orbește un mesaj cu o schemă normală de semnătură oarbă, îl trimite semnatarului
- Semnatarul semnează mesajul orb, trimite înapoi utilizatorului
- Utilizatorul îl dezactivează și verifică în raport cu cheia publică a semnatarului, ca și în cazul unei semnături obișnuite obișnuite - „blind HMAC”, așa cum este propus și dovedit nesigur, este incapabil de acest lucru, dar se poate face aici, deoarece semnarea oarbă se face cu o schemă de semnătură oarbă normală, asimetrică, iar autentificarea bazată pe hash este utilizată abia mai târziu.
- Utilizatorul generează un hash al mesajului și al semnăturii (mai degrabă decât al mesajului și o cheie ca în HMAC) și îl atașează mesajului.
- Utilizatorul trimite mesaj și hash către verificator
- Verificatorul primește mesajul și, în mod independent, îl semnează cu cheia privată a semnatarului (partajată cu verificatorul, deoarece cheile simetrice sunt în schemele HMAC).
- Verifier compară hash-ul furnizat de utilizator cu cel generat de acesta
- Dacă hashurile se potrivesc, utilizatorul a dovedit că semnatarul a semnat mesajul, fără a fi necesar să includă o semnătură mai lungă decât hash-ul său.
Se pare că o astfel de schemă ar putea reduce costul general de stocare și transfer de semnături relativ lungi către verificator.În plus, se pare că cerințele privind funcția hash pot fi neobișnuit de puține - un atac preimagine asupra funcției hash, de exemplu, nu ar părea să reprezinte o amenințare, deoarece ambele părți cunosc deja mesajul folosit pentru a-l genera și nici un atac prin care oricare dintre părți ar putea genera o coliziune hash (hashurile sunt folosite doar pentru a dovedi că utilizatorul deține o semnătură validă pentru mesaj - utilizatorul ar trebui să cunoască hash-ul mesajului său și o semnătură validă pentru ca acesta să caute chiar și o coliziune hash care să rezulte în același hash, astfel încât să se potrivească cu hash-ul generat de verificator). Într-adevăr, hash-ul trebuie să fie sigur doar pentru ca utilizatorul să poată ghici cu succes hash-ul mesajului său și o semnătură validă fără a obține acea semnătură - adică trebuie să fie suficient de dificil să forțezi un hash valid pentru un mesaj „online”. , comunicând cu verificatorul. Forța brută offline a hash-ului nu pare practică, deoarece utilizatorul nu ar putea verifica o ghicire la un hash față de mesajul său offline fără de asemenea fiind capabili să inverseze hash-ul la o semnătură (mult mai lungă, din întâmplare-validă) și să verifice semnătura cu cheia publică - probabil ar face mai bine să încerce să forțeze o semnătură validă sau o cheie de semnare pentru semnătura oarbă subiacentă schema, apoi generați un hash din asta.
Nu am reușit să găsesc referințe la vreo schemă de autentificare oarbă care funcționează astfel. Este fezabilă o astfel de schemă? Există defecte flagrante în el, de securitate sau de altă natură?
TL;DR pot fi evitate defectele de securitate cunoscute ale unei scheme HMAC oarbe fără unele dintre implicațiile legate de dimensiunea semnăturii unei scheme de semnătură oarbă, folosind o schemă de semnătură oarbă la semnare, dar având ca utilizator să trimită semnătura și să regenereze semnătura respectivă și hash pe partea verificatorului folosind cheia privată a semnatarului, apoi comparând hash-urile?
