înregistrare Logare
Puncte:2
phantomcraft avatar Crypto

Care ar fi dezavantajele blocurilor de dimensiuni foarte mari în cifrurile bloc?

drapel pf
phantomcraft

Să presupunem că cineva creează un cifr de bloc cu 8192 de octeți din dimensiunea blocului (65536 de biți) sau poate 16384 de octeți din dimensiunea blocului (131072 de biți).

Care ar fi ea dezavantaje peste un cifr de bloc cu dimensiuni mai mici de bloc, cum ar fi 128 sau 256 de biți?

88
0 + 0
Paul Uszak avatar
drapel cn
Paul Uszak
Nu s-ar potrivi pe un Arduino?
1
Răspunde
drapel et
user93353
Să presupunem că aveți o dimensiune de bloc de 65536 biți și textul simplu este de 65537 biți sau (65536*k) + 1 biți, atunci ar trebui să completați ultimul bloc cu 65535 biți - ceea ce este o risipă. În plus, cred că blocurile mari devin ineficiente
0
Răspunde
Paul Uszak avatar
drapel cn
Paul Uszak
@user93353 Acesta este un punct interesant. Unul dintre motivele prostești pentru care anti-paderele vin împotriva tampoanelor unice este că devine dificil să criptezi un hard disk de 12 TB. Cu toate acestea, sugerați că oamenii ar putea trimite mesaje mici. O dihotomie?
0
Răspunde
Paul Uszak avatar
drapel cn
Paul Uszak
Dihotomia ar crește în faptul că cripto-ul modern este conceput pentru cel mai mic numitor comun față de hardware-ul vi. O singură mărime trebuie să încapă toate/toate ouăle într-un singur coș. Niciun alt domeniu al efortului uman nu urmează acest principiu, dar se potrivește NSA ca minimizarea suprafeței de atac. Deci nu ar fi permis.
0
Răspunde
drapel et
user93353
@PaulUszak - „Totuși sugerezi că oamenii ar putea trimite mesaje mici” - nu, nu sugerez că oamenii pot trimite mesaje mici. Chiar dacă este un mesaj mare, dar dimensiunea mesajului este (65536*k) + 1 biți, se întâmplă aceeași risipă de umplutură.
1
Răspunde
drapel et
user93353
@PaulUszak - există și alte motive pentru a nu folosi cifrurile de flux în FDE - https://crypto.stackexchange.com/a/53544/3941
1
Răspunde
r3mainer avatar
drapel us
r3mainer
O altă problemă ar fi latența. Dacă criptați un flux MP3 de 64 kbps cu o dimensiune de bloc de 65536 biți, atunci veți avea o întârziere de codare de 1 secundă la capătul de transmisie (posibil și la capătul de recepție, în funcție de lățimea de bandă a canalului).
0
Răspunde
Puncte:2
kelalaka avatar Crypto
drapel in
kelalaka

  • Problemă de umplutură: Dacă cineva folosește un mod de criptare bloc precum CBC, atunci are nevoie de umplutură și nu uitați că umplutura este întotdeauna aplicată indiferent de dimensiune. Chiar dacă dimensiunea 65536 $*k$ atunci este necesar un nou bloc complet. Nu este clar cum se poate aplica umplutura PKCS#7, deoarece acceptă blocuri de până la 256 de octeți. Există și alte căptușeli ușor de aplicat, cum ar fi adăugarea 1 apoi zerouri apoi codificarea dimensiunii de umplutură.

    În criptografia modernă, suntem departe de modurile de umplutură, folosim moduri precum AES-GCM și modurile ChaCha20-Poly1305 sunt moduri de criptare autentificate fără palete.

  • Numar de runde: Dacă luăm în considerare Rijndael care necesită o rundă suplimentară la 32 de blocuri, un cifr de bloc similar va necesita 2048 de runde pentru a atinge același nivel de securitate (rețineți că aceasta este cu adevărat o estimare aproximativă). Acest lucru creează o latență pentru prima ieșire. ~148 de ori mai lent decât prima ieșire a AES-256. Deși această latență poate să nu fie importantă pentru mesageria pe Signal, există locuri în care latența nu este de preferat.

  • Problemă cu dimensiunea cheii: În SPN, folosim cheia pentru x-sau pentru valorile rotunjite. Dacă dimensiunea cheii este mai mică decât dimensiunea blocului, aceasta este cu adevărat o problemă de securitate care poate duce la atacuri liniare și diferențiale noi posibilități. Prin urmare, trebuie să generați, să schimbați transmisii și să stocați o cheie cu dimensiunea de 65536 de biți.

  • Problema de implementare: ținând deoparte implementarea în timp constantă a software-ului, în hardware o astfel de dimensiune va necesita mai mult spațiu de implementat. Acest lucru va crește costul implementării și va necesita mai multă putere decât cifrurile bloc de dimensiuni mai mici.

  • Problemă cu dimensiunea mesajului: pentru mesaje mai scurte decât dimensiunea blocului, acest lucru este foarte comun în bazele de date, dacă se folosește modul CBC, aceasta va crea o problemă de dimensiune. Da, cu modul bazat pe CTR se poate atenua acest lucru, cu toate acestea, se va petrece mai mult timp pentru a cripta/decripta decât cifrurile mai scurte de dimensiunea unui bloc.

  • Post Quantum: Nu există niciun avantaj al acestui lucru pe post-cuantic, deoarece AES-256 este deja securizat împotriva algoritmului optim al lui Grover.

  • Avem nevoie de cifruri bloc mai mari de 128 de biți?

    Da. De exemplu, dacă AES a fost standardizat exact ca Rijndael, atunci problemele aleatorii nonce ale AES-GCM nu vor mai fi probleme pentru noi. Noncele aleatorii de dimensiunea 256 vor fi protejate de coliziuni sub aceeași cheie.

  • Avem cifruri bloc mai mari de 256 de biți?

    Da, ChaCha20 prietenos cu procesorul care are o ieșire de 512 biți în modul CTR. Cu XChaCha20, are o bună apărare împotriva coliziunilor nonce cu dimensiunea sa de 192 de biți nonce.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.