Puncte:1

În general, cum se ocupă platformele de mesagerie e2e cu modificările aduse structurii datelor criptate?

drapel tz

Sunt un neprofesionist care încearcă să-mi aprofundez înțelegerea despre cripto și mesageria privată, construind o „platformă” de mesagerie criptată (dovadă de concept) centralizată, end-to-end.

Mesajele sunt trimise de dispozitive către „server” (care rulează pe Pi-ul meu în rețeaua mea de acasă) unde sunt stocate și de unde pot fi preluate de către destinatari printr-un apel API. Serverul știe doar minimul necesar pentru a distribui corect mesajele în timp ce textul mesajului este criptat și întregul mesaj este semnat corect.

Acum mă confrunt cu următoarea provocare: vreau să redenumesc o proprietate a formatului de mesaj utilizat de aplicațiile client (gândiți-vă la JSON: message.body â message.content). Problema acum este că (1) toate mesajele anterioare sunt stocate pe server în vechiul format și (2) un client „vechi” poate încerca să trimită mesaje unui client „nou”, ceea ce mă obligă să rezolv cumva această nepotrivire între formatele mesajelor comunicate.

Dacă cheile private ar fi disponibile pentru server, aceasta ar fi o problemă banală: pur și simplu transformați mesajul în formatul de mesaj așteptat de destinatar. Dar din moment ce încerc să fiu cu adevărat privat și cheile private sunt cunoscute doar de proprietarii lor, aceasta nu este o opțiune. Mesajele nu pot fi modificate de către server.

Simt că în centrul acestei probleme se află o provocare mai fundamentală, despre care sunt sigur că oameni mult mai capabili decât am venit cu soluții și pentru care există abordări standardizate. Prin urmare iată întrebarea mea: În general, cum gestionează soluțiile de mesagerie e2ee (de exemplu, semnal, matrice) modificările aduse structurii datelor criptate? Ce abordări există, cu excepția tăierii versiunilor vechi și a aruncării oricărui istoric al mesajelor?

Vă cer scuze dacă această întrebare sună vagă sau este prea largă. Sunt doar un noob care încearcă să fac imaginea de ansamblu.

Mulțumesc mult.

Maarten Bodewes avatar
drapel in
Analiza sau decriptarea nu este deloc diferită: ambele au nevoie de cod specific. În general, se rezolvă prin introducerea unui număr de versiune în partea de text simplu a mesajului (și, de preferință, inclusiv în calculul semnăturii și/sau în informațiile AAD ale unui cifru autentificat). Dacă nu aveți un număr de versiune acum, trebuie să-l introduceți. Uitați-vă la alte protocoale de securitate a transportului E2E; vor avea în general un astfel de număr de versiune.
drapel kr
Această întrebare este în afara subiectului pe Crypto SE. Această întrebare este de fapt despre designul software care acceptă mai multe versiuni API. Ar trebui să fie migrat la SO sau la Software Engineering SE.
Puncte:3
drapel ng

Aceasta este problema informatică generică a compatibilității înapoi, îngreunată de cripto.

În IT, o modalitate obișnuită de a gestiona compatibilitatea cu versiunea anterioară este de a avea un câmp de versiune la începutul structurilor de date, permițând aplicațiilor să decidă dacă recunosc formatul și să îl gestioneze dacă pot. Noile aplicații se ocupă de formate vechi, cel puțin în perioada de tranziție. Acest lucru poate fi extins la încărcăturile utile criptografice având câmpul versiune clar, iar restul criptat/autentificat conform câmpului versiune.

Atunci când metoda de criptare/autentificare nu se schimbă, nu există nicio problemă specifică criptografiei, iar mecanismele obișnuite pentru a face față structurilor de îmbogățire a datelor fără întreruperi de compatibilitate vor face (de ex.în JSON, este posibil să adăugați câmpuri noi pe care aplicațiile vechi le vor omite). În cele ce urmează presupun că cripto s-a schimbat, iar un câmp de versiune permite detectarea asta.

Problema acum este că (1) toate mesajele anterioare sunt stocate pe server în vechiul format și (2) un client „vechi” poate încerca să trimită mesaje unui client „nou”, ceea ce mă obligă să rezolv cumva această nepotrivire între formatele mesajelor comunicate.

Dacă noul client poate încă descifra vechiul format, niciunul nu este o problemă. Acesta este drumul de urmat!

Adevărata problemă grea este atunci când un client „nou” trimite un mesaj. Există multe opțiuni, niciuna dintre ele nu este perfectă. Câteva din acestea:

  • Clienții noi folosesc întotdeauna noul format, pe care clienții vechi nu îl vor înțelege.
  • Clienții noi folosesc vechiul format până la un declanșator (schimbarea datei, mesajul de la server), apoi folosesc noul format. Clienții vechi nu vor fi utilizabili după schimbare, iar clienții noi nu se vor bucura de noile funcții ale noului format până la acel eveniment.
  • Clienții noi folosesc un nou format după declanșare sau dacă există vreun indiciu că receptorul (sau toți receptorii) îl înțelege, de ex. deoarece clientul expeditor a primit un mesaj autentificat de la (toți) destinatarii(i) care indică suportul noului format, poate implicit prin utilizarea acestuia.
  • Clienții noi generează ambele formate până la declanșare și le trimit pe ambele către server, care le stochează; clienții vechi preiau formatul vechi, clienții noi preiau noul și în caz de eșec preiau formatul vechi. Serverul trebuie să gestioneze solicitările în ambele formate și are nevoie de mai mult spațiu de stocare și mai mult trafic în perioada intermediară.
korolev avatar
drapel tz
Raspuns foarte clar. Mulțumesc foarte mult.

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.