Controllo della password nel contesto della crittografia simmetrica

Question

Controllo della password nel contesto della crittografia simmetrica

#1 da (3 voti)

2

Sono a conoscenza del fatto che i codici a blocchi come AES non dispongono di meccanismi integrati per verificare l'integrità dei dati al momento della decrittografia, sebbene alcune modalità operative possano fornire questo.

Ho giocato con 7-zip, che utilizza AES-256 / CBC. Ho crittografato un sacco di file e deliberatamente ho danneggiato l'azzeramento di un paio di byte. Ho osservato che, come previsto, prima ho azzerato i byte, più file sarebbero corrotti.

Ho anche notato che fornire una password errata non bloccherebbe affatto la decompressione. Solo dopo aver decompresso l'intero archivio, 7-zip segnalerebbe che la password potrebbe essere sbagliata. Dal momento che salva i checksum dei file, può dire se sono corrotti. Questo ha senso.

Ora inserisci Adobe Acrobat X. Ho crittografato un PDF (ancora AES-256). Con mia sorpresa, il danneggiamento dei byte nel file crittografato sembrava non avere alcun effetto osservabile sul risultato. Notare che Acrobat X crittografa anche i metadati e ho modificato qualcosa ben oltre il punto in cui mi aspettavo che i metadati fossero comunque.

Ero ancora in grado di vedere la lettura dell'intero file. Ho quindi rimosso la password da entrambi i file originali e "corrotti" e ho fatto confronti byte per byte. Ho notato che oltre ad alcuni intervalli di indirizzi in cui presumo siano memorizzati i metadati (poiché differiscono ogni volta che decodifico lo stesso file), c'era solo un singolo blocco in cui 16 byte (in modo casuale la dimensione del blocco AES) sono diversi.

Anche Acrobat sembra essere in grado di verificare se una password è corretta senza tentare di decodificare nulla, il che implica che ha un hash di esso (o qualcosa) memorizzato da qualche parte.

Ha senso farlo (verificare che una password o una chiave siano corrette senza tentare di decifrare)? Non sarebbe così più semplice per un utente malintenzionato utilizzare la password per rinforzare la password?
Sono corretto nel ritenere che Acrobat usi la BCE? C'è un vantaggio?
In che modo si comportano le modalità AE quando si tratta di:
- La verifica di una chiave è corretta prima che venga tentata la decrittografia
- Se un byte di testo cifrato è corrotto accidentalmente, come influisce su ciò che viene dopo?

encryption passwords integrity

posta quantumSoup 17.10.2012 - 21:50

fonte

1 risposta

Leggi altre domande sui tag encryption passwords integrity

Esiste qualcosa come OWASP top 10 per le applicazioni BizTalk? [chiuso] Sicurezza della re-crittografia con un elenco di chiavi basate su password pre-calcolate

score 3 · Accepted Answer

Se lo schema di crittografia utilizza CBC e modifichi un bit del crittografato , quindi, al momento della decrittazione, questo avrà due effetti: farà scomparire il blocco corrispondente, e capovolgerà il bit corrispondente nel blocco successivo (16 byte ulteriormente, con AES). Non modificherà il resto dei dati. Questo è abbastanza diverso da ciò che accade se si capovolge un bit dei dati clear , durante la crittografia: quello cambierebbe tutti i blocchi successivi, fino alla fine del file.

Per le altre modalità, le cose cambiano. Sfogliando un bit di dati crittografati, è possibile capovolgere lo stesso bit dei dati chiari con le modalità OFB e CTR. Con ECB, altera esattamente un blocco. Con CFB, modificherà tutti i blocchi successivi.

Per le modalità autenticate, il CTR è spesso usato internamente (ad esempio con EAX ) ma il punto è discutibile perché l'integrità check rileverà l'alterazione e la riferirà (è ancora fino all'applicazione per sbarazzarsi di qualsiasi cosa decifrata in quel caso).

Includere un controllo esplicito della password è consuetudine (ad es. OpenPGP lo fa) e non indebolisce la crittografia, se fatto correttamente . Fondamentalmente, la password deve prima essere lenta-hash (con un salt), e allora un hash della chiave risultante viene usato come checksum. In ogni caso, nessun attaccante sane decodificherà l'intero file per ogni password che tenta: decodifica i primi due o tre blocchi, per vedere se trova un'intestazione di file dall'aspetto realistico. Non possiamo fare affidamento sulla velocità di decrittografia come sostituto per l'hashing lento.