Cifrurile blocate se ciocnesc cu chei diferite
Dacă există o pereche de chei cu text simplu $m,k$ care dă un text cifrat și există o altă cheie, pereche de mesaje $m_1,k_1$ care produce, de asemenea, același text cifrat, este aceasta în esență o problemă similară cu o coliziune hash?
Da, este similar cu coliziunea hash, există un caz de atac dacă se folosește aceeași cheie, vezi secțiunea bonus. Pentru diferite chei nu dezvăluie nimic.
Dacă utilizați CTR (orice mod de streaming), atunci dacă aveți o coliziune cu text cifrat, aceasta nu va dezvălui mesajele, deoarece
$$m_1 \oplus o_1 = c_1 = c_2 = m_2 \oplus o_2$$ deoarece
$$m_1 m_2 \oplus = o_1 \oplus o_2$$ iar acest lucru nu va dezvălui mesajele chiar dacă ghiciți unul.
Și, în mod similar, modul CBC va rezista coliziunilor sub diferite taste.
Posibilitate de coliziune a textului cifrat
să presupunem că criptăm AES „lună” cu cheia „morehotquestions” obține „fjydhpdag”. și criptăm „soare” cu cheia „hotnetworkquestions” obținând și „fjydhpdag”. este chiar posibil acest lucru?
Dacă considerăm că AES este un PRP, atunci avem exact aceeași condiție ca și atacul de ziua de naștere. Probabilitatea ca două blocuri simple să aibă același text cifrat este $1/2^{128}$ pentru blocul BCE.
Găsirea unuia pentru noi mult mai ușor, deoarece AES este inversabil. Luați în considerare ECB pentru un caz ușor.Deoarece AES este inversabil, luați un text cifrat și decriptați-l cu două chei diferite. Apoi veți primi două mesaje diferite. Desigur, ele nu sunt neapărat semnificative, aceasta este o modalitate ușoară de a găsi/arăta acest lucru.
Sisteme de semnătură precum RSA-Sign
Sistemele de semnătură folosesc un hash al mesajului pentru a semna. Una dintre modalitățile de a falsifica atacatorul are nevoie de un al doilea atac pre-imagine asupra funcției hash. Ce se întâmplă dacă avem un semnatar rău intenționat sau un secretar rău intenționat al semnatarului? Să presupunem că folosesc MD5 pentru care coliziunea este iminentă (nu folosiți MD5 și SHA-1 pentru semnătură), atunci pot găsi două mesaje cu aceleași valori hash. $h(m_1) = h(m_2)$ cu $m_1 \neq m_2$ apoi cele două valori $$\operatorname{RSA-Sign}(h(m_1)) = \operatorname{RSA-Sign}(h(m_2))$$ sunt la fel.
Utilizați întotdeauna funcții hash criptografice rezistente la coliziuni precum SHA-256, SHA-512, SHA-3, BLAKE2 etc. pentru a atenua acest atac.
Partea bonus: Cifrurile blocate se ciocnesc cu aceeași cheie
Da, există atacuri și preocupări în legătură cu acest lucru; ca Sweet32;
Sweet32: atacuri de naștere asupra cifrurilor bloc pe 64 de biți în TLS și OpenVPN
Pe scurt, pentru un cifru bloc de dimensiune $b$, dacă criptați $2^b$ blocuri sub aceeași cheie se poate obține o coliziune pe textul cifrat al modului CBC pe care îl $c_i = c_j$ cu $i \neq j$. Acesta este;
$$m_i \oplus c_{i-1} = m_j \oplus c_{j-1}$$
Apoi, folosind proprietățile CBC, putem obține
$$m_i \oplus m_j = c_{1-1} \oplus c_{j-1}.$$
După cum putem vedea, acesta este doar x-sau al blocurilor de text simplu un atacator pasiv poate exploata.
Am vorbit doar despre modul CBC, cu toate acestea, pagina menționează mai multe și a lăsat să investigheze similar cu CBC;
Acest lucru este deosebit de important atunci când folosiți moduri comune de operare: avem nevoie de cifrurile bloc să fie securizate cu până la $2^n$ interogări, dar majoritatea modurilor de operare (de ex. CBC, CTR, GCM, OCB, etc.) sunt nesigure cu mai mult de $2^{n/2}$ blocuri de mesaje (legatul zilei de naștere).
Desigur că suntem aproape nu mai folosesc cifruri de dimensiunea unui bloc de 64 de biți. Cu toate acestea, acest atac este posibil chiar dacă criptați prea multe date folosind aceeași cheie. S-ar putea spune criptarea a $2^{64}$ datele sunt prea multe, nu vom cripta o astfel de dimensiune. Atunci avem un argument mai profund, 50% din atacul de ziua de naștere este prea mult pentru avantajul unui atacator, este departe de a fi neglijabil. Ei pot căuta chiar și probabilități mai mici de a dezvălui un bloc de mesaje. Ar trebui să te limitezi la $2^{32}$-blocare pentru a reduce avantajul atacatorului.
