Pachetul de cărți care se dovedește corect folosit de client și server

Să presupunem că un server joacă un joc de blackjack cu un client, iar cărțile sunt amestecate și împărțite de către server. Amestecarea în sine poate fi sau nu corectă, dar ceea ce trebuie arătat este că cărțile împărțite nu au fost modificate în timpul jocului, adică: după începerea mâinii, cărțile din pachet nu au în secret ordinea schimbată de server.

Mă gândeam la următoarea soluție folosind criptografie și am vrut să obțin feedback dacă ar fi acceptabilă pentru un sistem de producție și, dacă nu, de ce nu:

Pasul 1) Serverul ar amesteca în secret un pachet de cărți într-o anumită ordine, spuneți următoarele (omitem costumul pentru simplitate): [3, 9, 2, ..., A]

Ar crea apoi următorul mesaj M:
M = "Amestecare carduri: [3, 9, 2, ..., A]. Număr aleatoriu: A96A...QT3"

Numărul aleatoriu este un număr aleatoriu pe care serverul îl generează intern și îl păstrează secret până la încheierea jocului. Lungimea sa ar fi suficient de mare pentru a preveni spargerea hash-ului de către client prin forța brută (să spunem că are 512 caractere lungime).

Acum serverul va hash M folosind sha-256 sau alt algoritm de hashing de încredere, de exemplu: hash(M)

Pasul 2) Înainte de începerea jocului, serverul trimite acest hash (M) către client, pe care clientul îl stochează. Clientul nu are de unde să-l cunoască pe M din ceea ce pot aduna.

Pasul 3) Jocul începe, cărțile sunt împărțite în ordinea amestecate, jucătorul ia decizii și jocul se încheie în sfârșit.

Pasul 4) Clientul vrea acum să știe că jocul a fost corect, adică: serverul nu a trișat modificând cărțile în timpul mâinii. Serverul trimite acum mesajul „M” clientului în text simplu pentru a arăta acest lucru.

Pasul 5) Clientul rulează hash(M) și vede că se potrivește hash(M) primit la pasul 1.

Este aceasta o modalitate corectă de a demonstra că jocul a fost corect, fără ca clientul sau serverul să poată trișa, excluzând posibilitatea ca amestecul în sine să nu fi fost aleatoriu? Dacă serverul ar modifica cărțile din amestecul inițial în timpul mâinii, atunci clientul ar vedea acest lucru în Pasul 5 (fie ordinea ar fi diferită transparent de client, fie hash-ul mesajului trimis în Pasul 4). ar fi diferit de cel trimis la pasul 2). De asemenea, un singur hash este trimis pe mână, astfel încât serverul nu poate genera un număr mare de hash-uri și le poate trimite separat, apoi îl alege pe cel mai bun pe parcursul mâinii.

Pentru a extinde răspunsul lui knaccc, este chiar posibil să folosiți scheme de angajament pentru a demonstra (până la un punct) că serverul nu a trișat în timpul amestecării, de ex. ca aceasta:

1. Serverul alege un număr aleatoriu de 128 de biți $x$ și un factor de orbire de 128 de biți $r_x$, și trimite angajamentul $c_x = H(x \,||\, r_x)$ către client.
2. Clientul alege un număr aleatoriu de 128 de biți $y$ și îl trimite la server. (Nu este necesar niciun angajament aici.)
3. Hash-ul serverului $x$ și $y$ împreună pentru a obține o sămânță de 128 de biți $s = H(x \,||\, y)$.
4. Serverul folosește $s$ ca o sămânță pentru un PRNG determinist și folosește ieșirea PRNG pentru a amesteca determinist pachetul.
5. Jocul se joacă cu pachetul amestecat.
6. La sfârșitul jocului, serverul dezvăluie $x$ și $r_x$, permițând clientului să verifice dacă pachetul a fost amestecat corect (și nu a fost modificat după ce a fost amestecat).

Rețineți că serverul poate sa încă trișează, într-un fel, inspectând pachetul amestecat după pasul 4 și întrerupând jocul (de exemplu, pretinzând că conexiunea a fost întreruptă) dacă nu-i place pachetul. Astfel, un client ar trebui să fie suspicios față de serverele care întrerup frecvent conexiunile între pașii 2 și 5, sau chiar în timpul jocului de la pasul 5. În mod ideal, ar trebui să existe o modalitate ca un client să solicite unui server să reia un joc întrerupt în orice moment, iar un client ar trebui să fie foarte suspect de serverele care refuză să facă acest lucru.

(Implementarea în siguranță a unui astfel de mecanism de reluare într-un mod care funcționează chiar dacă serverul se blochează și uită starea jocului pare fezabilă, dar probabil în afara domeniului de aplicare al acestui răspuns. Pune o nouă întrebare dacă ești interesat.)

De asemenea, rețineți că valoarea orbitoare $r_x$ nu este de fapt necesar aici, din moment ce $x$ ea însăși are deja suficientă entropie pentru a face angajamentul de forțare brută imposibil de realizat. De fapt, ar fi puțin mai sigur să omiteți $r_x$ și doar fă $x$ în sine 256 în loc de 128 de biți.

Lungimile biților de $y$ și $s$ poate fi, de asemenea, crescut dacă se dorește; 128 de biți este doar un minim sigur și practic. Nu are rost să faci $s$ mai mare decât lungimea combinată a $x$ și $y$ împreună, totuși.