Puncte:2

Înțelegerea „argumentului de derulare”

drapel cm
AXX

Am citit întrebările conexe despre acest SE, dar încă nu înțeleg de ce putem folosi argumentul de derulare.Mai exact, derularea mi se pare o superputere cu adevărat puternică și nu înțeleg de ce presupunerea atât de puternică nu subminează forța concluziei. Sigur, verificatorul adversar nu învață nimic de la un simulator care poate manipula timpul, dar dacă o entitate este atât de puternică încât poate manipula timpul, nu sunt surprins că este sigură împotriva oricărui adversar și nici nu sunt convins că alte entități fără această putere rămâne în siguranță.

M-am gândit că poate această abilitate de rebobinare are ceva de-a face cu accesul oracolului simulatorului la verificator, astfel încât simulatorul să poată efectua de fapt „priviți înainte” pentru a afla ce întrebare va pune verificatorul și apoi pregătește răspunsurile în consecință. Dacă acesta este cazul, atunci sunt convins că nu există într-adevăr nicio superputere, deoarece este ceva pe care verificatorul însuși îl poate face și deci urmează proprietatea zero-cunoștințe.

Puncte:4
drapel gd

Din câte știu eu, ai înțeles ideea. „Rebobinarea” este doar strategia de „privire” făcută posibilă prin accesul oracol al simulatorului la verificator

De obicei, este denumită „superputere” pentru că este o capacitate pe care un Prover nu o are în timpul execuției normale a protocolului, altfel soliditatea ar putea fi compromisă (din moment ce simulatorul poate produce o transcriere convingătoare a interacțiunii fără să știe nimic, ar putea uzurpa identitatea unei înșelăciuni). doveditor pretinzând că dovedește o afirmație falsă)

În ceea ce privește faptul că simularea este exact ceva ce verificatorul poate face singur, este adevărat: simulatorul nu trebuie să știe nimic pentru a dovedi ZKness, și cine este un candidat mai bun decât Verificatorul pentru rolul cuiva care nu știe?!


EDITĂ PENTRU RĂSPUNS LA COMENTARIU DE URMAR:

În capitolul 6 din Tutoriale despre fundamentele criptografiei (Springer), Yehuda Lindell scrie:

În primul rând, cineva s-ar putea întreba cum este posibil să derulați „tehnic” verificatorul. De fapt, atunci când luăm în considerare cunoștințele zero-box, acest lucru este banal. Mai exact, simulatorului i se oferă acces oracol la următoarea funcție de mesaj V*(x, z, r, ·) a verificatorului. Aceasta înseamnă că furnizează o transcriere m' = (m1, m2,...) a mesajelor primite și primește înapoi următorul mesaj trimis atunci când V* are intrare x, intrare auxiliară z, ​​bandă aleatoare r și mesaje primite m'

deci este doar următorul mesaj, nu întreaga transcriere rezultată la sfârșitul interacțiunii (dacă asta a fost îndoiala ta).

Având în vedere definiția de mai sus a funcției mesajului următor (unde provocarea doveditorului aparține mesajelor primite anterior de verificator), „modul evident” mi se pare greșit pentru un verificator V* generic (aka potențial înșelat).

Dacă verificatorul este sincer (deci provocarea este sincer „aleatorie” - chiar dacă nu este neapărat distribuită uniform) puteți pur și simplu să inversați ordinea în care simulatorul primește mesajele (deci mai întâi rezultatul, apoi provocarea, apoi angajamentul): BTW, este strategia de a demonstra că protocolul de identificare Schnorr este HVZKP (omițând -de dragul simplității- că avem de-a face cu distribuții și nu doar cu valori reale).

Dar dacă avem de-a face cu un verificator V* care poate înșela (și acesta este cazul presupus al secțiunii 8.7 a prelegerii dvs.), poate că provocările sunt în funcție de angajamente, deci nu sunt independente reciproc, așa că cea mai bună strategie este să încercați toate rezultatele. până îl găsești pe cel valid (sau, adoptând punctul de vedere al prelegerii, având în vedere un rezultat, începi să încerci toate angajamentele până când funcția produce provocarea „potrivită”)... oricum trebuie să testezi un număr de cazuri care cresc exponențial dacă aveți doar un grad de libertate, așa că un simulator PPT nu se poate descurca, adică ZK nu este dovedit:

Aceasta înseamnă că după ce simulatorul se derulează, este ca și cum întregul protocol începe din nou de la zero. Acest lucru implică faptul că numărul așteptat de derulări este exponențial și că nu putem construi un simulator PPT, ceea ce implică faptul că nu putem demonstra proprietatea zero-cunoaștere.

Deci, nu există contradicție între definiția anterioară a derulării înapoi și concluzia primului paragraf din secțiunea 8.7 a prelegerii dumneavoastră.

Recunosc că nu m-am gândit prea mult de ce un simulator trebuie să fie PPT și nu poate -să spunem- să fie nelimitat din punct de vedere computațional, cel puțin în principiu: aș dori să aud de la alții despre el. Între timp, presupunerile mele educate sunt următoarele:

  • "considerăm insolubile acele sarcini care nu pot fi efectuate de mașina PPT" (Goldreich, Fundamentul Criptografiei Volumul I pag. 19)
  • pentru orice utilizare reală, suntem întotdeauna constrânși să folosim entități eficiente (incluși dovezitorii, chiar dacă teoretic nu există nicio problemă să le considerăm nelimitate)
  • existența unui simulator este o condiție suficientă, dar nu necesară pentru ZK, așa că folosirea acestei paradigme înseamnă deja pierderea oricăror ipoteze cele mai cuprinzătoare: în acest scenariu pare acceptabil să se folosească o definiție prea prudentă.
AXX avatar
drapel cm
AXX
Am o altă întrebare ulterioară acum... Dacă înțelegem într-adevăr rebobinarea ca anticipare, atunci putem demonstra proprietatea de cunoaștere zero a unui protocol cu ​​3 runde (menționat în [această notă](https://courses.grainger.illinois) .edu/cs598dk/fa2019/Files/lecture08.pdf) în 8.7) în mod evident: efectuăm o privire înainte pentru a găsi toate mesajele $n$ pe care verificatorul le va cere, apoi ne pregătim angajamentele în prima etapă în consecință.Deci, înțelegerea mea despre oracol este greșită? Preia de fapt următorul mesaj sau doar rezultatul final atunci când interacționează cu verificatorul?
baro77 avatar
drapel gd
raspunsul in raspunsul editat :)
AXX avatar
drapel cm
AXX
Mulțumesc pentru editare, cred că acum am în sfârșit o înțelegere solidă a subtilităților din argumentele de derulare. Într-adevăr, nu mi-am dat seama niciodată că provocările pe care verificatorul le trimite pot fi „adaptative” la angajamentele din prima fază.
Puncte:2
drapel ng

Rebobinarea a program este comună în calcul. O modalitate de a o numi este să luați a instantaneu, apoi re-rulați-l, așa cum permit mediile de execuție virtuale. O aplicație finalizează un joc arcade clasic fără a reporni de la zero după o greșeală. Tot ce este nevoie este să decidem în ce punct vrem să derulăm înapoi; realizarea unei copii a întregii stări a mașinii (RAM și registre) în acel moment; apoi mai târziu punând totul la loc.

Cel puțin unele dovezi care utilizează derularea funcționează în acest fel: returnăm un program atacator ipotetic și oracolele la un stat salvat, apoi repornim cu o bandă aleatorie diferită/răspunsuri oracol diferite din acel punct. Controlăm banda aleatoare (deci noile valori ale oracolelor), la fel ca o gazdă VM poate controla RNG-urile mașinii virtuale client. Această capacitate ne permite să transformăm acel program de atacator ipotetic în ceva care atacă un alt protocol, dovedind astfel securitatea acestui protocol ulterior implică că nu poate exista un astfel de program de atacator ipotetic.

Mai degrabă decât o „superputere”, văd aceasta ca o construcție care folosește un mediu de calcul puțin mai puternic, la fel ca un computer gazdă pentru o mașină virtuală.

Notă: nu sunt sigur dacă această analogie funcționează pentru derulare ca în simulatorul ZK.

baro77 avatar
drapel gd
În opinia mea, o infrastructură a VM-urilor este doar un exemplu REAL al modului în care un acces oracol cutie neagră la subrutina _next_message_ a verificatorului ar putea fi atins într-un scenariu din „lumea reală” din zilele noastre. Cu toate acestea, atunci când avem de-a face cu ZK Simulator, ne interesează starea de existență a acestuia, nu cum să-l implementăm.. așa că „superputere” aici se referă nu la un mediu computerizat specific, ci la capabilități permise în afara constrângerilor de dovezi interactive (alias regulile protocolului, grosier). vorbitor)
AXX avatar
drapel cm
AXX
Multumesc pentru raspuns! Îmi dă o idee despre cum se poate derula un program într-o lume fizică. Se pare că acest lucru necesită ca atacatorul să ruleze într-un mediu virtual controlat de apărător, ceea ce presupun că este ceva pe care scenariul ZK nu îl permite (sau, altfel, un probator rău intenționat poate câștiga cu ușurință, așa cum a menționat @baro77).

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.