Puncte:6

Este sigur să faci Shamir cheia împărțită pe o cheie în blocuri și să recombini?

drapel cn
mkl

Ieri am facut o relatii cu publicul la o bibliotecă cripto python pentru a accepta dimensiunile cheilor mai mari de 16 octeți pentru schema de partajare secretă Shamir.

În prezent, acceptă 16 octeți, după cum urmează:

$$ K = \{ 0, 1 \}^{128} $$ $$ S_{128}(m, n, K) = s_1, ... , s_n $$

Pentru a nu schimba funcția de bază și pentru a accepta chei mai mari, am decis să împart cheia și să rulez funcția de câte ori este nevoie și să concatenez acțiunile. Exemplu de cheie de 32 de octeți de mai jos, folosind o funcție de împărțire shamir limitată de 16 octeți.

$$ K = \{ 0, 1 \}^{256} = \{ 0, 1 \}^{128} | \{ 0, 1 \}^{128} = K_A | K_B $$ $$ S_{128}(m, n, K_A) = s_{A1}, ... , s_{An} $$ $$ S_{128}(m, n, K_B) = s_{B1}, ... , s_{Bn} $$ $$ s_1 = s_{A1} | s_{B1} $$

Câțiva oameni din PR au spus că acest lucru este nesigur, deoarece puteți ataca fiecare parte în cazul a 32 de octeți, fiecare parte a 16 octeți, înseamnă că puterea cheii provine de la 32 de octeți (2**256) la 2 * (2 ** 128) = 2**129.

Nu cred că acest lucru este adevărat, deoarece nu există niciun atac pe o parte care să vă spună că ați reușit să vă permită să treceți pe cealaltă parte.

Pentru a lua-o la extrem, chiar dacă funcția shamir doar suportată 1 octet (8 biți) dimensiunea cheii, veți menține în continuare securitatea făcând funcția în blocuri și concatenând acțiunile rezultate.

Spune-mi ce crezi.

kelalaka avatar
drapel in
Există o metodă prin care se poate verifica cei 32 de octeți pentru a împărți și cuceri secretul? Aceasta este cheia acestui lucru. Care este scopul de utilizare a secretului?
drapel cn
mkl
Cheia este pentru enc simetric (de exemplu, AES256) sau pentru asimetric (de exemplu, cheie privată ed25519).
kelalaka avatar
drapel in
Laturile secrete partajate pot fi rău intenționate? i.e. își pot construi partea lor și pot pune forța brută pe cealaltă?
drapel cn
mkl
Să presupunem că pragul de recuperare a cheii este de 3 acțiuni. Dacă presupunem că adversarul are 2 acțiuni, atunci ar fi lăsat să încerce să reconstruiască partea finală. Nu cred că adversarul ar avea vreun avantaj să descopere câte un bloc pe rând. i.e. nu există nicio sumă de control sau hash care să spună bloc 1 succes (din câte știu eu...).
kelalaka avatar
drapel in
SSS are secretul perfect, prin urmare, a avea o acțiune sau n-1 nu ajută, toate au aceeași probabilitate să fie secretul. Cred că ei iau în considerare acest lucru, în loc de secretul perfect de 256 de biți, aveți două secrete perfecte de 128 de biți, prin urmare nu sunt egali. În cele din urmă, incertitudinea tuturor biților este aceeași pentru atacator, deci nu este adevărată.
Puncte:6
drapel my

Nu cred că acest lucru este adevărat, deoarece nu există niciun atac pe o parte care să vă spună că ați reușit să vă permită să treceți pe cealaltă parte.

Motivul pentru care nu crezi că acest lucru este adevărat este că este, de fapt, neadevărat.

Cu o schemă secretă Shamir, $t-1$ shares nu oferă absolut nicio informație despre secretul partajat. Adică, singurul atac disponibil adversarului este să ignore valorile acțiunilor (care nu-i spune nimic) și să ghicească în mod direct cheia completă AES-256 (care, după cum știm cu toții, este complet imposibil de realizat).

Câțiva oameni din PR au spus că acest lucru este nesigur, deoarece puteți ataca fiecare parte în cazul a 32 de octeți, fiecare parte a 16 octeți

Acești oameni greșesc - nu există niciun „atac” disponibil pe Shamir's care să permită cuiva cu $t-1$ share pentru a recupera secretul (sau, de altfel, pentru a obține orice informații despre el) - acest lucru rămâne adevărat chiar dacă presupunem că atacatorul are capacități de calcul infinite.

Pentru a lua-o la extrem, chiar dacă funcția shamir doar suportată 1 octet (8 biți) dimensiunea cheii, veți menține în continuare securitatea făcând funcția în blocuri și concatenând acțiunile rezultate.

Ați putea să o luați și mai extrem de atât - dacă fiecare secret ar fi doar un bit (și astfel există un total de 256 dintre ele), adică adversarul știa din față că fiecare dintre ei fie deține valoarea 0, fie valoarea 1, el încă nu ar putea obține alte informații despre cheie.

Pe de altă parte; există o măsură de precauție pe care trebuie să o luați - trebuie să presupuneți că polinomul aleatoriu pe care îl generați pentru a proteja fiecare jumătate de 128 de biți este selectat independent. Dacă (de exemplu) sunt aceleași, cu excepția acestui termen constant, raționamentul de mai sus nu se aplică.

drapel cn
mkl
Mulțumesc pentru răspuns și da, fiecare bloc primește noi coeficienți polinomi. Cu toate acestea, toți folosesc un câmp: https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/Protocol/SecretSharing.py#L81
poncho avatar
drapel my
@mkl: folosirea aceluiași câmp este bine...
drapel ar
Poate că merită remarcat faptul că, în timp ce folosirea schemei lui Shamir pentru a partaja biți individuali este într-adevăr perfect sigură, irosește ceva spațiu, deoarece încă trebuie să utilizați un câmp cu cel puțin $n+1$ elemente pentru a genera $n$ acțiuni. În timp ce biții individuali se mapează perfect la elementele GF(2), acel câmp este inutil pentru partajarea secretă a lui Shamir, deoarece puteți genera cel mult o partajare (!).
poncho avatar
drapel my
@IlmariKaronen: ei bine, da, am spus că va fi sigur - nu am spus niciodată că va fi 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.