Puncte:1

Dimensiunea contorului în modul CTR

drapel us

Dacă am înțeles bine, în modul CTR criptez nonce sau IV împreună cu contorul ca bloc, care apoi este XORed cu textul simplu. Pentru blocul următor, increment contorul. Există o dimensiune fixă ​​a contorului pentru a putea itera prin toate blocurile sau începe din nou la 0 la un moment dat?

De exemplu, dacă un algoritm cu o dimensiune de bloc de 16 octeți, teoretic aș putea repeta peste 4,3 miliarde de blocuri (68,8 GiB) când contorul meu este de 4 octeți. Dar ce se întâmplă dacă datele mele devin și mai mari? Cât de mare este atunci contorul, astfel încât IV-ul să fie încă păstrat și în primul bloc nu sunt umpluți mulți octeți doar cu 0?

Mulțumesc anticipat

Luqus avatar
drapel us
Nu chiar. Mai degrabă aș știu cum se ocupă acest lucru în mare parte de algoritmi standard, cum ar fi Java Cipher în modul CTR.
Maarten Bodewes avatar
drapel in
@kelalaka Este incorect, Java a avut întotdeauna contor (modul `"CTR"`), îl folosiți ca de ex. `"AES/CTR/NoPadding"`. Java 10 este deja destul de vechi, dar [Java 6](https://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html#Cipher) îl avea deja.
Maarten Bodewes avatar
drapel in
Răspunsul meu la întrebarea legată este: „Deși contorul este adesea specificat ca separat de nonce în protocoale, implementările au de obicei un contor care are aceeași dimensiune cu dimensiunea blocului. În acest caz, nonce face parte din cei mai semnificativi biți. al contorului de start”. Deci acesta este răspunsul generic: depinde de bibliotecă. Furnizorul standard în Java utilizează un contor big endian de 16 octeți / 128 de biți. Dacă doriți să nu se reverse în nonce, va trebui să limitați singur cantitatea de blocuri/octeți criptați.
Maarten Bodewes avatar
drapel in
Dacă doriți, pot migra la [so], dar întrebarea ar trebui să fie specifică Java. Cazul generic a primit deja răspuns și nu pot găsi o înșelăciune ușoară pe [so].
Maarten Bodewes avatar
drapel in
Remarcă finală, am adăugat „NIST intră în detaliu despre cum să construiți blocuri de criptare în NIST SP 800-38a, apendicele B, observând la sfârșit că contoarele sunt practic specifice protocolului și că cerința de unicitate trebuie testată separat.” la răspunsul meu din celălalt link, m-am gândit că ar putea fi de interes pentru tine.
Luqus avatar
drapel us
@MaartenBodewes mulțumesc pentru informațiile suplimentare, care ar trebui să-mi răspundă la întrebare.
Maarten Bodewes avatar
drapel in
@Luqus Ei bine, putem oferi oricând și mai multe informații: vezi [aici](https://stackoverflow.com/a/70323458/589259) despre dimensiunile nonce din interiorul 128 biți IV / contor. Dacă vă uitați la [arppoximations simple](https://en.wikipedia.org/wiki/Birthday_attack#Simple_approximation) de pe Wikipedia pentru data de naștere, atunci puteți calcula de ex. care este riscul pentru o coliziune dacă aveți nevoie de o anumită dimensiune a contorului (cu dimensiunea nonce fiind ceea ce rămâne).
kelalaka avatar
drapel in
Amintiți-vă că NIST spune contor de 64 de biți și 64 de biți, totuși, [ar trebui să vă opriți mult mai mult decât aceasta] (https://crypto.stackexchange.com/a/85572/18298) dacă utilizați în schimb un PRP ca AES a unui PRF ca ChaCha.
kelalaka avatar
drapel in
@MaartenBodewes Da, ai dreptate. De obicei verific din nou. Cred că m-am uitat doar la [Javax](https://docs.oracle.com/javase/10/docs/api/javax/crypto/Cipher.html)

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.