Puncte:0

Generare sincronizată de numere aleatoare

drapel cn

Permiteți-mi să încerc să reformulez problema, deoarece ar putea ajuta puțin. Cerințele sunt următoarele:

  1. La începutul conexiunii lor, cele două puncte finale efectuează un Diffie-Hellman pentru a deriva cu o cheie comună $K$.
  2. Apoi EP1 trebuie să genereze o valoare aleatorie de 48 de biți $R$ și trimiteți-l la EP2. Această valoare aleatorie trebuie să aibă următoarele două proprietăți: (a) an atacatorul nu este capabil să ghicească următoarele valori aleatorii pe care le generează EP1 și (b) EP2 este capabil să verifice că $R$ vine într-adevăr de la EP1.
  3. Cele două puncte finale împărtășesc, de asemenea, o valoare a informațiilor de sincronizare $T$, care este ca un contor de temporizare și este de 64 de biți. Nu știu mai multe, știu doar că această valoare este unică în fiecare asociație și este cunoscută de ambele PE.
  4. Prin asociere mă refer la succesiunea completă a pașilor 1-4 de mai sus. Dacă EP-urile se deconectează, rulează acele mesaje de la început, dar ambele EP-uri șterg cheia $K$ și să stabilească unul nou în următoarea asociație.

Deci, pentru a modifica puțin răspunsul meu de mai sus, mă gândeam la următoarea soluție:

EP1 EP2
------------------------------------------|
1.s1 = AES-CTR(K,T||contor,K) ---------->|
2.R1 = s1 XOR K-------------------------->| 
                                         | 3. s1' = AES-CTR(K,T||contor,K)
                                         | 4. R1' = s1' XOR K
                                         | Verificați R1' == R1

La pasul 1, EP1 folosește AES în modul CTR, cu cheie $K$, câmpul nonce/counter să fie o concatenare a $T||counter$, iar mesajul de criptat este din nou $K$.

La pasul 2, valoarea cu aspect aleatoriu $s_1$ de la pasul 1 se xorează cu aceeași cheie $K$ iar ultimii 48 de biți sunt trimiși la EP2. reutilizam $K$ ca mesaj de intrare pur și simplu pentru că este o valoare cunoscută pentru EP2 și astfel poate verifica valoarea criptată. Dar spuneți-mă dacă aceasta este o practică proastă.

În pașii 3 și 4, EP2 efectuează aceleași calcule, deoarece toate valorile sunt comune și în pasul 5 verifică dacă $R_1'==R_1$. Dacă da, aceasta înseamnă că EP1 este autentificat deoarece trebuie să folosească cheia corectă $K$, Si deasemenea $R_1$ valorile nu trebuie să fie previzibile.

Vedeți vreo defecte sau redundanțe în schema mea? Ar îndeplini cerințele menționate la începutul postării mele?

Maarten Bodewes avatar
drapel in
Informațiile despre sincronizare pot fi ghicite, cred că sunt utile numai împotriva atacurilor de reluare. Putem presupune că sămânța este undeva între 128 și 256 de biți? Bănuiesc că pentru un CSPRNG, putem presupune că primii 3 pași nu sunt mai buni decât `RNG(timing info | seed)` apropo (concatenarea ambelor semințe).
Jimakos avatar
drapel cn
@MaartenBodewes, mulțumesc. Informațiile de sincronizare sunt trimise clar și pot fi interceptate de oricine. Sămânța poate fi între 128-256 de biți. Primii trei pași sunt de fapt o ușoară adaptare a standardului ANSI X9.17. Se inserează aici de pe [wikipedia](https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator#Standards): Obține data/ora curentă D la rezoluția maximă posibilă. Calculează o valoare temporară t = TDEak(D) Calculează valoarea aleatorie x = TDEAk(s â t), unde â denotă exclusiv sau pe biți. Actualizează sămânța s = TDEak(x â t)
Aman Grewal avatar
drapel gb
Poate tangenţiale, dar cum vă asiguraţi că rămân sincronizate? EP1 trimite date către EP2, dar EP2 nu le primește niciodată. EP1 își avansează starea, dar EP2 nu.
Maarten Bodewes avatar
drapel in
TDEA (adică triplu DES) este un cifru bloc, un PRP, nu un RNG. Deci, în acest caz, pașii separati au mai mult sens. Bineînțeles, asta ar însemna și un seed de 8 octeți, ceea ce este dăunător pentru securitate, dar principala diferență este, desigur, $k$ de acolo: o cheie care asigură securitatea. Pentru un RNG fără cheie, schema are mai puțin sens.
Jimakos avatar
drapel cn
@AmanGrewal Nu am inclus toate părțile protocolului, pur și simplu pentru că sunt complet ignorant. Putem doar presupune că informațiile de sincronizare sunt acolo pentru a sincroniza cele două puncte finale.
Jimakos avatar
drapel cn
@MaartenBodewes într-adevăr, acesta este motivul pentru care nu am pus în mod explicit TDEA, ci mai degrabă un RNG generic care poate accepta semințe mai mari. Cu toate acestea, nu este așa încât să pot folosi AES-CTR în modul 128/256 ca RNG? În acest caz, pot folosi cheia disponibilă (seed) ca intrare cheie în algoritm și poate un hash de 128/256 biți (timing_info | seed) ca cealaltă intrare. Tu ce crezi?
Maarten Bodewes avatar
drapel in
Cred că nu ar lăsa o mare parte din schema originală în loc și că parametrul de intrare „seed” nu mai este necesar, deoarece valorile aleatoare sunt deja complet dependente de „seed”. Înseamnă, de asemenea, că sămânța ar trebui să respecte cerințele unei chei simetrice (AES) (fiind complet randomizată), ceea ce poate impune cerințe suplimentare schemei. Orice analiză de securitate ar trebui apoi efectuată separat de schema originală.
Jimakos avatar
drapel cn
Am reformulat întrebarea complet, puteți verifica această versiune deoarece ar putea clarifica lucrurile?

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.