Puncte:0

Schimbul de chei este autentificat și confidențial?

drapel in

Am făcut un program de mesagerie privată și aș dori să verific dacă nimic nu este stupid în utilizarea criptografiei. Sunt amator și nimic nu este pentru producție. Multumesc in avans.

Schimburile de mesaje sunt criptate end-to-end cu AES-OCB. Cheia de sesiune este schimbată după cum urmează:

La început, se încarcă cheia privată și se generează cheia publică. Serverul își trimite cheia publică către client. Clientul verifică cheia publică a serverului cu un fișier know_host. În acest fișier, adresele gazdei sunt stocate hashing (sha256) cu cheia lor publică (sha256). Clientul verifică dacă cheia publică primită este cea corectă, în caz contrar amprenta sha256 a cheii publice este afișată pentru verificarea de către utilizator.

Clientul generează cheia de sesiune de 128 de biți și o criptează cu cheia publică a serverului. Clientul trimite către server: cheia de sesiune criptată, cheia sa publică, semnătura RSASSA-PSS (sha256) a cheii de sesiune.

Serverul verifică identitatea clientului cu propriul fișier know_host. Decriptează cheia de sesiune. Verifică semnătura cheii de sesiune cu cheia publică a clientului.

Ambele părți sunt autentificate și au cheia de sesiune, începe comunicarea normală.

Puncte:1
drapel kr
  1. Schema ta are nici un secret înainte. Dacă un atacator obține într-o zi cheia privată a serverului, toate sesiunile anterioare pot fi decriptate: cheile de sesiune pot fi decriptate și astfel sesiunile corespunzătoare pot fi decriptate. Vezi detalii Aici.

  2. Schema ta este predispusă la reluare atac. Dacă atacatorul interceptează traficul și cunoaște semnificația unei anumite părți a datelor criptate, atunci atacatorul poate trimite din nou aceste date. Dacă se face în cadrul aceleiași sesiuni, atunci se folosește în continuare aceeași cheie de criptare și va fi imposibil de detectat dacă mesajul a fost cu adevărat trimis de cealaltă parte sau dacă a fost trimis de atacator. În funcție de semantica mesajului, poate fi periculos. Vezi detalii Aici.

SAI Peregrinus avatar
drapel si
De asemenea, metoda pe care o folosește clientul pentru a cripta cheia de sesiune nu a fost specificată. Dacă este RSAES-OAEP, este în regulă, dar aproape orice altceva va avea unele avertismente sau va fi de-a dreptul nesigur. Și, fără îndoială, este mai bine să utilizați RSA-KEM sau ECDH pentru a genera un secret partajat, decât să criptați și să trimiteți unul.
drapel kr
@SAIPeregrinus: Sigur. Și tunelul SSH sau TLS ar fi mai bun decât protocolul auto-realizat.
SAI Peregrinus avatar
drapel si
De acord. Sau cel puțin un protocol Noise, dacă SSH sau TLS (sau Wireguard) nu funcționează din orice motiv.
drapel in
Pentru criptarea cheii de sesiune folosesc RSAES-OAEP. Dacă folosesc ECDH pentru schimbul de chei de sesiune, se va rezolva problema „fără secretizare înainte”?
drapel kr
@Laurent57: Nu chiar. Ar trebui să fie ECDHE, ECDH efemer. Atunci vei avea secret.
drapel in
Vă mulțumesc pentru răspunsurile utile, prețuiesc feedback-ul dvs.

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.