Puncte:3

Cum ar folosi un grup rău intenționat de co-semnatari o coliziune hash pentru a semna un mesaj neintenționat?

drapel ar

Conform BIP340:

Cu toate acestea, un dezavantaj major al acestei optimizări este că găsirea coliziunilor într-o funcție hash scurtă este ușoară. Acest lucru complică implementarea protocoalelor de semnare securizate în scenariile în care un grup de semnatari care nu au încredere reciproc lucrează împreună pentru a produce o singură semnătură comună (vezi Aplicațiile de mai jos). În aceste scenarii, care nu sunt surprinse de modelul SUF-CMA datorită presupunerii unui singur semnatar onest, o strategie de atac promițătoare pentru co-semnatarii rău intenționați este găsirea unei coliziuni în funcția hash pentru a obține o semnătură validă pe un mesaj pe care un cosemnatar onest nu a intenționat să-l semneze.

În versiunea de Schnorr folosită de BIP340, argumentele funcției hash sunt date de următoarele:

$e=\text{hash}(R || P || m)$

Pentru a semna un mesaj neintenționat, un semnatar rău intenționat ar trebui să găsească o coliziune între două mesaje diferite:

$e=\text{hash}(R||P||m_0)=\text{hash}(R||P||m_1)$

Dar asta implică $m_0$ nu se angajează înainte de a calcula $R$. Pare ciudat că acest „atac” necesită convingerea semnatarului onest să semneze un anumit mesaj $m_0$ după și-au calculat deja particularul $R_H$ valoare. Dacă $m$ au fost comise înainte de a genera $R$ mai este posibil acest tip de atac?

Puncte:1
drapel in

Ideea este că tu (și eu) nu am citit corect documentul;

În partea dvs. citată, ei au în vedere atacarea variantei semnăturii Schnorr. Pentru a simplifica, voi folosi o notație mai scurtă ca $H(m)$

Da, ei iau în considerare coliziunea pentru atac. Dacă există o semnătură $semn(prv,H(m))$ și vrei să forjați ai nevoie de atacurile pre-imagine asupra funcției hash $H$ ca să poți pretinde că $m'$ acesta a fost mesajul dorit.

În partea citată a documentului Bip340, acesta este cazul. Doriți ca cosemnatarul dvs. să semneze un mesaj pe care în mod normal nu vrea să îl semneze. Deci găsiți niște perechi de coliziune $m_i \neq m'_i$ astfel încât $H(m_i) = H(m'_i)$ cu proprietate suplimentară; cosemnatarul tău va semna pentru $m_i$ dar nu pentru $m'_i$ pentru care al doilea este în beneficiul tău, dar nu al lor. Nu vor fi bănuiți $m_i$ să semnezi și ei vor semna și tu vei folosi $m'_i$ ca mesaj semnat pentru a obține un avantaj față de cosemnatarul dvs.

mai târziu au scris ca;

Deoarece am dori să evităm fragilitatea care vine cu hashurile scurte, the $e$ varianta nu oferă avantaje semnificative. Noi alegem $R$-opțiune, care acceptă verificarea lotului.

Dacă te angajezi $m$ înainte de semnătură, atunci nici coliziunea, nici imaginile prealabile nu vor funcționa. Sa vedem;

  • $commit = H(m)$

  • calculati $R$

  • pregătiți hașul pentru semnătură

    $\text{hash}(R || P || m)$

În acest caz, cosemnatarul rău intenționat trebuie să atace $commit$ pentru a găsi un al doilea mesaj $m'$ astfel de $H(m) = H(m')$, adică executați un al doilea atac înainte de imagine și acesta va rămâne valabil pentru $\text{hash}(R || P || m) = \text{hash}(R || P || m')$, de asemenea. Deloc posibil.

kelalaka avatar
drapel in
@knaccc Este prea greu să găsești acea muncă pe ambele. Nu am informații despre probabilitatea atacurilor cu mai multe preimagine pentru astfel de cazuri. Cel puțin ar trebui să fie mai greu decât căutarea pe 128 de biți.
knaccc avatar
drapel es
Cred că motivul pentru care această întrebare a provocat atât de multă confuzie este că indică faptul că problema este că o pereche de semnături $(e, s)$ cu hashuri scurte ar „complica implementarea protocoalelor de semnare securizate în scenariile în care un grup de semnatarii care se neîncrede reciproc lucrează împreună pentru a produce o singură semnătură comună”. Cu toate acestea, deoarece nu au explicat niciodată care ar fi protocolul de semnare pentru varianta $(e, s)$ pe care au respins-o, trebuie să ne dăm seama care ar fi fost acel protocol, pentru a vedea cum ar fi vulnerabil la ziua de naștere. ciocniri.
kelalaka avatar
drapel in
@knaccc Am găsit unele dintre BIP-uri foarte prost scrise nu aproape de rfcs.
drapel ar
Am găsit acest [post de blog](https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da) de la un cercetător de la Blockstream ca fiind destul de util. Se pare că ar putea exista situații în care $m$ este partajat *după* schimbul de nonces. De exemplu, nonces-urile pot fi pre-partajate în Lightning ca o optimizare pentru a reduce numărul de runde de comunicare. Rețineți, totuși, postarea pe blog spunea că această optimizare este nesigură și că numai angajamentele nonce ar trebui să fie pre-partajate, așa că nu sunt sigur dacă trimiterea de mesaje după nonce s-ar întâmpla vreodată în practică.

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.