Puncte:0

Este posibilă o scurgere de cheie privată RSA dacă semnez și decriptez?

drapel id

Este posibilă scurgerea datelor cheii private dacă atacatorul controlează cererea de semnare?

Toată lumea știe $N$ și $E$ pentru că sunt publice.

Serverul meu este proiectat pentru a decripta cererile primite, care sunt criptate cu cheie publică.

Faceți semn și pentru datele decriptate care au SHA-2 returnează semnul RSA pentru acele date.

Este posibil ca un atacator să învețe cheia mea privată?

Testez acest lucru în atelierul meu local în scopuri educaționale.

Folosesc mesajul criptat cu cheie publică PKCS#1 pentru solicitarea primită; datele sunt decriptate de cheia mea privată și au SHA-2, așa că doar semnez și returnez datele semnate către client.

Exemplu în Python:

Generarea mesajului și a perechii de chei:

mesaj = struct.pack('>IIII', 0, 0, 0, 1)
(pub, priv) = rsa.newkeys(512) //doar de exemplu, știu că nimeni nu folosește 512 biți

Solicitare primită:

criptat = pkcs1.encrypt(mesaj, pub) 

Operațiuni cu serverul:

decriptat = pkcs1.decrypt(criptat, priv)
semnătură = pkcs1.sign(decriptat, priv, „SHA-256”)

și întoarceți răspunsul.

fgrieu avatar
drapel ng
Sunt lăsate deoparte atacul pe canalele laterale (sincronizare, analiza puterii...)? Se poate presupune că cheia privată $(N,D)$ este folosită doar pentru a calcula funcția $X\mapsto X^D\bmod N$? Dacă da la ambele: nu există nicio modalitate cunoscută ca cheia privată (sau o cheie care funcționează) să se scurgă. Dar poate că vă interesează și ca serverul să fie abuzat pentru a descifra sau semna, ar putea exista atacuri care să permită asta. Independent: vă rugăm să clarificați. Folosiți „semnătura” atunci când se referă la o bucată de date și „semnați” pentru acțiunea de a face o semnătură. Ce se face hashing cu SHA2? Exact cum este folosit rezultatul? Criptarea și semnarea folosesc umplutură?
rockymaster avatar
drapel id
Mi-am actualizat întrebarea și am adăugat și eșantion.
fgrieu avatar
drapel ng
Rămâne mult loc de îmbunătățire a formei: _"face semn și pentru datele decriptate care au SHA2 returnează semnul rsa pentru acele date"_ -> _semnează datele decriptate cu padding folosind SHA2 și returnează semnătura corespunzătoare_; cod [formatare](https://meta.stackexchange.com/questions/22186/how-do-i-format-my-code-blocks), poate [Mathjax](https://crypto.meta.stackexchange.com /a/1070/555). Și lipsește esențialul: atacurile pe canale laterale (timing, analiză de putere...) asupra bibliotecilor cripto Python sunt considerate atacuri valide? Acestea pot „scurge datele cheii private”.
Puncte:1
drapel ng

Din exemplu, reiese că criptarea și semnătura folosesc unele moduri de umplutură în PKCS#1; probabil RSAES-PKCS1-v1_5 pentru criptare și RSASSA-PKCS1-v1_5 cu SHA-256 pentru semnătură.

Este posibilă scurgerea datelor cheii private?

Din cate stim noi, Nu, faptul că este descifrat un mesaj și l-a semnat cu aceeași cheie nu poate scurgerea datelor cu cheie privată. Acest lucru este independent de schemele exacte de umplutură utilizate pentru criptare și semnătură: pur și simplu nu știm cum se poate folosi o cheie privată RSA. $(n,d)$ limitat la calcul $x\mapsto x^d\bmod n$ într-o cutie neagră fără canale laterale poate scurgerea datelor cu cheie privată.

Printre lucruri similare care s-ar putea întâmpla:

  • Implementarea ar putea scurge cheia privată printr-un canal lateral; cum ar fi un program troian practic care rulează pe platformă sau Analiza Putere Diferenţială. Există multe alte canale secundare de care să ne temem.
  • Implementarea decriptării RSAES-PKCS1-v1_5 ar putea fi printre multe care sunt vulnerabile la vreo variantă de atac Bleichenbacher. Acest lucru ar putea permite transformarea serverului într-un oracol care permite (cu suficiente interogări) calcularea funcției $x\mapsto x^d\bmod n$ pentru arbitrar $x$, oferind un echivalent (foarte lent) cu cunoașterea cheii private unui atacator care poate comunica cu serverul.

Nu este corect din punct de vedere academic să folosiți aceeași pereche de chei publice/private pentru criptare și semnătură, dar cu cele patru moduri de criptare și semnătură în PKCS#1 nu permite niciun atac cunoscut. Cele mai slabe verigi aparente din lantul de securitate sunt

  • Însăși funcționalitatea serverului: permite obținerea semnăturii pentru orice se potrivește cu limita de dimensiune pentru criptare (117 octeți).
  • Modulul de 512 biți, care poate fi factorizat (așa era deja posibil în secolul XX).
  • Utilizarea decriptării RSAES-PKCS1-v1_5 pe text cifrat neautentificat din deschis.

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.