Doar pentru a adăuga câteva detalii suplimentare Răspunsul excelent al lui Kodlu:
Pentru a partaja câteva date secrete folosind Împărtășirea secretă a lui Shamir peste câmpul finit $\mathrm{GF}(k)$, mai întâi trebuie să codificați acele date ca $m ⥠1$ elemente ale câmpului (care sunt reprezentate în mod natural ca numere întregi variind de la $0$ la $k-1$), și, de asemenea, atribuiți fiecare partajare pe care doriți să generați un element distinct diferit de zero al câmpului ca ID de partajare (adică $x$ coordonata la care polinomul generator de cote este evaluat pentru a produce acea cotă).
Apoi aplicați procesul de generare a acțiunilor, care vă va oferi mai multe acțiuni, fiecare constând din $m$ elemente ale domeniului $\mathrm{GF}(k)$ (plus ID-ul share). Prin construcție, aceste acțiuni sunt distribuite uniform și $t-1$ înțelept independent, unde $t$ este parametrul pragului de reconstrucție al schemei, adică orice subset de $s < t$ a acțiunilor nu se distinge de $s$ secvente de $m$ elemente de câmp alese independent uniform la întâmplare. În special, ca un corolar slab al acestui fapt, toate elementele de câmp care cuprind acțiunile sunt în mod necesar distribuite uniform între $0$ și $k-1$, inclusiv.
Acum, să presupunem că datele secrete pe care doriți să le partajați sunt binare și sunt codificate ca șir de $n$ biți. Dacă se întâmplă să utilizați un câmp binar, astfel încât $k = 2^b$ (si daca $n$ este un multiplu al $b$), apoi maparea secretului într-o secvență de elemente de câmp este foarte simplă: doar tăiați $n$-bit șir în $m = \frac nb$ bucăți de $b$ biți, fiecare dintre care se mapează în mod natural la un element de câmp. Și din moment ce fiecare element al $\mathrm{GF}(2^b)$ mapează, de asemenea, fără ambiguitate la un șir de $b$ biți, acțiunile dvs. pot fi reprezentate și ca $n$-bit șiruri de biți (plus ID-ul partajării) pur și simplu prin concatenarea (reprezentărilor binare ale) elementelor câmpului din fiecare partajare.
(Dacă lungimea datelor $n$ este variabilă și nu neapărat un multiplu întreg al $b$, poate fi necesar să aplicați unele umplutura pentru a indica fără ambiguitate lungimea sa înainte de a o împărtăși, dar aceasta este totuși doar o complicație minoră. Și dacă datele dvs. sunt codificate ca octeți de opt biți și nu aveți nevoie de mai mult de 255 de partajări, atunci puteți utiliza doar $\mathrm{GF}(2^8)$ și sări peste umplutură.)
Ce ar fi dacă tu nu vrei să folosești un câmp binar, totuși? Apoi aveți câteva opțiuni:
Alegeți cel mai mare $b$ astfel încât $2^b < k$, împărțiți datele în $b$-biți, mapați-le în elemente de câmp și partajați-le. Principalul dezavantaj al acestui lucru este că elementele de câmp aleatorii din acțiuni vor fi nu se potrivesc $b$ biți (din moment ce $2^b < k$), așa că va trebui să le codificați folosind $b+1$ biți fiecare, irosind cel puțin $m$ biți pe acțiune. (Codificarea cu lungime variabilă după partajare nu va ajuta aici, deoarece nu puteți comprima datele uniform aleatorii. Codificarea cu lungime variabilă inainte de partajarea este nesigură, de atunci lungimea partajării dvs. ar scurge informații despre secret.)
De asemenea, nu le puteți aranja pe amândouă $b$ și $b+1$ pentru a fi valori „rotunjite” convenabile, cum ar fi 8, 16, 32, 64, 128 sau 256, ceea ce înseamnă că fie bucățile tale de date, fie bucățile partajate vor avea inevitabil o lungime incomodă. De exemplu, să presupunem că doriți să partajați chei de criptare pe 256 de biți; ai putea fie sa alegi $b = 256$, caz în care acțiunile dvs. ar avea o lungime de 257 de biți (și, dacă doriți să utilizați un câmp principal, ar trebui să faceți calculele modulo un prim de 257 de biți) sau $b = 255$, caz în care va trebui să împărțiți cheile în două elemente de câmp, rezultând partajări de 512 biți. Sau ai putea folosi, să zicem, $b = 32$ (și, să zicem, câmpul prim $\mathrm{GF}(2^{32}+15)$, care este puțin dificil de lucrat folosind aritmetica pe 64 de biți, dar nu imposibil, mai ales dacă nu aveți nevoie de execuție în timp constant) și ajungeți cu 33 $ \time 8 = 264 $ acțiuni după câteva amestecări, care ar putea fi o cale de mijloc decentă.
Utilizați o conversie generală de bază din binar în bază $k$ pentru a vă codifica în mod optim datele (adică, interpretați $n$-bit date binare ca un număr de la $0$ la $2^n-1$, apoi exprimați acel număr în bază $k$), și o conversie inversă de bază $k$ pentru a converti acțiunile înapoi în binar. Veți mai pierde niște biți, așa că acțiunile dvs. vor fi mai lungi decât datele, dar numai cu o cantitate constantă. Dezavantajul este că conversia radix este mai lentă și mai complicat de implementat decât simpla amestecare a biților. De asemenea, aproape sigur vei avea nevoie de un fel de schemă de umplutură dacă lungimea ta secretă nu este fixă. (Și asigurați-vă că utilizați întotdeauna $m = \lceil n \log_k 2 \rceil$, chiar dacă valoarea ta secretă s-ar încadra într-o bază mai mică $k$ cifre, pentru a evita ca lungimea cotei să scurgă informații despre secret.)
Acum, niciuna dintre aceste complicații nu este de netrecut, dar ele do complică implementarea și face codificarea partajării mai puțin eficientă. În comparație, chiar dacă trebuie să implementați $\mathrm{GF}(2^b)$ aritmetica de la zero, folosirea unui câmp binar este încă mai simplă.
