Puncte:2

Verificarea unei predicții de viitor

drapel us
svm

Încerc să găsesc un algoritm care să demonstreze că cineva cunoaște un scurt mesaj secret (de exemplu, o predicție a viitorului) înainte de a-l dezvălui în cele din urmă.

De exemplu:

Alice știe ce temperatură va fi afară mâine, vrea să-i demonstreze lui Bob că a avut-o fără să dezvăluie numărul până mâine. Bob, pe de altă parte, are nevoie de Alice pentru a nu putea să-și falsească predicția după fapte.

Am venit cu o schiță de schemă care arată astfel:

  1. Alice generează lung șiruri aleatorii $r_s, r_p$.

  2. Alice trimite $hash(r_s . r_p . T)$, si $r_p$ lui Bob.

    Aici $T$ este temperatura prezisă (un număr din două cifre).

  3. A doua zi Alice trimite $r_s$, și $T$ lui Bob, astfel încât să poată verifica acum că Alice știa $T$ la pasul 2, dovedind că Alice a prezis viitorul.

Este în regulă?, sau îmi poți indica o soluție mai bună? Dacă este în regulă, ce proprietăți speciale ar trebui $hash$ funcția are dacă există, cu excepția faptului că este sigură criptografic?

Puncte:3
drapel es

Schema dvs. funcționează, dar nu este nevoie să aveți $r_p$.

Dacă eliminați $r_p$, atunci este important să conveniți în avans care este lungimea de biți a factorului dvs. de orbire $r_s$ va fi, astfel încât angajamentul să nu fie maleabil prin decizia de a elimina sau adăuga biți la începutul $T$ în timp ce adăugați sau eliminați biți la ceea ce pretindeți mai târziu a fi valoarea factorului orbitor $r_s$.

Alice trimite apoi $hash(r_s \mathbin\| T)$ (Unde $\mathbin\|$ înseamnă concatenare), iar mai târziu dezvăluie $r_s$ și $T$. Utilizați doar orice hash sigur din punct de vedere criptografic care are un nivel de securitate de cel puțin 128 de biți, cum ar fi SHA256. Utilizați cel puțin 128 de biți pentru $r_s$ și asigurați-vă că este uniform aleatoriu, pentru a-l împiedica pe Bob să forțeze valorile brute ale $r_s$ pentru a-ți descoperi predicția în avans.

S-ar putea să fiți îngrijorat în plus de faptul că Bob poate face derivate din angajamentul lui Alice, ceea ce este posibil dacă hash-ul este vulnerabil la atacurile cu extensie de lungime.

Scenariul este: Alice se angajează la o predicție și anunță angajamentul, apoi Bob anunță imediat un angajament bazat pe lungimi de extindere-atac în care ceva este atașat la predicția lui Alice. Bob nu își poate deschide angajamentul până când Alice îl deschide pe al ei dezvăluind factorul orbitor. Apariția unui factor orbitor duplicat va fi suspectă, dar numai dacă cineva este atent.

Puteți evita atât această amenințare, cât și necesitatea de a conveni în avans asupra lungimii biților a factorului orbitor, utilizând una dintre următoarele metode:

  1. Calculați angajamentul ca hash(hash(factorul orb) $\mathbin\|$ hash (predicție)).

  2. După cum subliniază @kelalaka, utilizați HMAC, cu factorul orbitor ca cheie. Prin urmare, angajament = HMAC-SHA256(factorul orb, predicție).

svm avatar
drapel us
svm
Da, am verificat de două ori și acum văd că r_p a fost într-adevăr inutil. Voi merge cu schema asta. Mulțumesc!
Puncte:1
drapel in
  • Pe ar trebui să rețineți că o simplă concatenare cu numai $r_s$ nu va funcționa;

    Comiterul îl poate păcăli pe verificator. Acest lucru se datorează concatenării simple. De exemplu $H(\texttt{100110||11})$ este angajamentul cu prognoza temperaturii este $3^\circ$ ( $\texttt{11}$ în binar). Dacă temperatura se dovedește $11^\circ$ atunci comiterul poate pretinde că acela secretul $r_s = \texttt{1001}$ iar predicția a fost $\texttt{1011}$. Aceasta funcționează, deoarece noua lor revendicare poate fi, de asemenea, interpretată ca fiind validă; $H(\texttt{1001||1011})$

    Pentru a atenua acest lucru; fie folosi

    • un delimitator public predefinit ca $\texttt{"<delimetru>}"$

      $$H(\texttt{100110<delimetru>11})$$

      sau

    • eliberați dimensiunea $r_s$ ca parte a angajamentului.

    Da, utilizați cel puțin 128 de biți, astfel încât chiar și minerul Bitcoin să aibă nevoie de preajmă $2^{34}$-an pentru a găsi o posibilă valoare de angajament, atâta timp cât funcția hash utilizată oferă rezistență înainte de imagine de cel puțin 128 de biți. Utilizați SHA-256, deoarece încă credem că SHA-256 are o securitate preimagine de aproximativ 256 de biți.

    Alternativ, este mai bine să utilizați $\operatorname{HMAC-SHA256}$ cu $r_s$ ca cheie sau utilizare mai bună $\operatorname{KMAC}$ al $\operatorname{SHA-3}$ care este o construcție mai ușoară decât $\operatorname{HMAC}$, deși HMAC este încă o fiară.

Schema din întrebare poate funcționa fără ca delimitatorii sau dimensiunea să fie dezvăluite

Acest lucru se datorează publicării documentului $r_p$ care sta ca delimitatori. Cu toate acestea, este mai bine să îl utilizați $\operatorname{HMAC,KMAC}$.

Dacă cineva dorește în continuare să folosească o funcție hash criptografică și există o teamă de atacuri de extensie de lungime asupra funcțiilor hash, utilizați SHA-3, BLAKE2 sau SHA-512/256. De fapt, nu există nicio teamă, deoarece atacul de extensie de lungime va schimba rezultatul hash.

În loc să utilizați o funcție hash diferită pentru diferite platforme de utilizare separarea domeniilor;

$$H(\texttt{fixedDomainSeperationTextForPlatfromA}||r_s||r_p||T)$$

Maarten Bodewes avatar
drapel in
Comentariile nu sunt pentru discuții extinse; această conversație a fost [mutată în chat](https://chat.stackexchange.com/rooms/133039/discussion-on-answer-by-kelalaka-verifying-a-prediction-of-the-future).

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.