Puncte:1

Securitatea căptușelii PKCS7

drapel us

Tocmai mi-am proiectat propria funcție de umplutură și am venit cu o problemă potențială care ar putea afecta securitatea criptării. După ce am remediat acest defect, am aflat că umplutura standard PKCS7 ar trebui să fie, de asemenea, vulnerabilă la un atac de text simplu cunoscut. Vă rog să mă corectați dacă greșesc în orice moment.

PKCS7 umple fiecare octet completat cu numărul total de octeți completați. De fiecare dată, se adaugă cel puțin un octet de umplutură, în cel mai rău caz un bloc întreg. Când operez un cifru în modul carte electronică de coduri, ultimul bloc ar putea fi ușor de ghicit pentru un atac de text simplu cunoscut. (În 1 din 16 cazuri de [dimensiune bloc], instantaneu) Exemplu de umplutură este prezentat mai jos.

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 04 04 04 04

Îmi dau seama că completarea tuturor octeților cu prostii aleatorii și a ultimului octeți cu numărul de octeți ar fi mult mai sigură. De ce nu este cazul într-un standard de umplutură atât de larg distribuit? Exemplul de mai jos nu este mai sigur?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

Mulțumesc anticipat.

kelalaka avatar
drapel in
Forger padding, utilizați moduri bazate pe PRF cum ar fi CTR și nu uitați niciodată că CBC este securizat IND-CPA, precum modul CTR. Deci niciun atac nu este fezabil. `CPA = Chosen Plaintext Attack`
Luqus avatar
drapel us
Mulțumesc pentru răspuns, dar dacă am folosit în mod special ECB, atunci ar trebui să existe un risc de securitate sau nu? De exemplu, în implementările standard în Java pentru ECB cu AES puteți **numai** selecta PKCS5 ca algoritm de umplutură care are aceeași slăbiciune. Mă întreb de ce acest lucru este implementat implicit, deși introduce un risc de securitate (independent de BCE însuși).
Paul Uszak avatar
drapel cn
Te-ai gândit să adaugi o formă de MAC/HMAC? Asta ajută la securitatea umpluturii.
kelalaka avatar
drapel in
Dacă utilizați ECB, sunteți deja pe calea greșită. ECB există pentru compatibilitate cu înapoi și pentru cei care știu ce fac. Puteți utiliza `ECB/nopadding` și puteți aplica umplutura. Umplutura te ajută doar dacă ai un singur bloc care poate elimina egalitatea, dacă ai mai mult de 1 blocuri, asta nu ajută deloc.
Luqus avatar
drapel us
Sunt clar despre numeroasele dezavantaje ale BCE, nu vă faceți griji. Dar imaginați-vă o situație în care ați fi forțat să utilizați BCE din orice motiv. De asemenea, știu despre `NoPadding` în Java, dar nu trebuie să implementați singur Padding când utilizați **doar** padding implementat `PKCS5`. De ce nu există o altă _implementare standard_?
kelalaka avatar
drapel in
Pentru că nimeni nu o folosește. cu mai mult de mulți ani în urmă, am folosit astfel de căptușeală pentru proiectul meu. padding este prietenul tău pentru a implementa astfel de paddind
Puncte:2
drapel in

Îmi dau seama că completarea tuturor octeților cu prostii aleatorii și a ultimului octeți cu numărul de octeți ar fi mult mai sigură. De ce nu este cazul într-un standard de umplutură atât de larg distribuit? Exemplul de mai jos nu este mai sigur?

53 65 63 72 65 74 20 74 65 78 74 2e --> 53 65 63 72 65 74 20 74 65 78 74 2e 5a 2c 12 04

Acest lucru este în principiu cunoscut ca Captuseala ISO 10126, compatibil cu Captuseala ANSI X9.23.

Mai întâi de toate, trebuie remarcat faptul că atacurile de tip oracle de umplutură sunt doar o parte dintr-un set mai larg de atacuri de oracle în text clar.Deci, dacă textul simplu decriptat poate genera orice eroare, aceleași probleme pot apărea atunci când sistemul încearcă să aplice textul simplu. De exemplu, este foarte ușor să creezi un Atacul oracle în text simplu folosind erorile unui decodor XML. Și mai ușor: dacă blocurile de text simplu constă în umplutură din partea stângă, atunci evident că ar eșua și un atac oracol de umplutură.

În al doilea rând, un text cifrat va fi acum acceptat (adică nu va genera o eroare de completare) 1 dată din 256 / 8 = 32 de ori (octetul final este evaluat 01 la 08) în loc de aproximativ o dată la 256 de ori (octetul final este evaluat 01 sau se valorează octeții finali 02 02 etc.). Acest lucru exclude utilizarea umpluturii pentru integritatea / autenticitatea mesajului.

În al treilea rând, ați atenuat atacul de padding oracle, dar nu l-ați eliminat complet. La urma urmei, octetul final va mai trebui evaluat. Considerăm un cifr rupt dacă orice poate fi învățat din textul simplu original.

În cele din urmă, nu ați eliminat căptușeala de deasupra capului.


Dacă presupui oricum supraîncărcare, atunci ai putea la fel de bine să adaugi o etichetă de autentificare, creată folosind un MAC sau un cifru autentificat. Acesta este motivul pentru care nu suntem foarte interesați de proprietățile de umplutură. Putem folosi un mod care nu necesită umplutură, adăugați eticheta de autentificare și avem un mod de criptare cu proprietăți de securitate mai bune, păstrând în același timp extinderea mesajelor limitată.

Maarten Bodewes avatar
drapel in
Fapt amuzant, am descoperit că lucrarea în timp ce arătam că criptarea XML fără generarea semnăturii XML este **nu** o idee bună. Și chiar dacă utilizați XML sig trebuie să acordați o atenție deosebită.

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.