Il danneggiamento di più byte di un zip crittografato lo rende irrecuperabile?

2

L'avversario può estrarre i dati da un archivio deliberatamente danneggiato?

Se archivi una cartella con 7zip e utilizzo una password (inclusa la crittografia dell'intestazione) ingannando alcuni byte in un particolare offset dell'archivio crittografato, rendere impossibile il recupero da software forense senza sapere in anticipo quali byte sono stati deliberatamente modificati?

Se N byte con offset O è stato modificato, un avversario che cerchi di eseguire la bruteforce dell'archivio ricostruisce correttamente sia l'offset corretto che i byte inalterati originali prima di provare a eseguire la bruteforcing della password di archivio, oppure esiste una scorciatoia per estrarre i dati dall'archivio crittografato in il caso che alcuni dati siano stati (deliberatamente) corrotti?

Supponendo, ad esempio, che 5 byte con offset N siano stati modificati e che l'avversario abbia solo una conoscenza incompleta dello stato di archivio originale, è possibile "indovinare" tutti i dati dei byte originali che costituiscono l'archivio prima di procedere con la bruteforcing di la password?

Qualcuno può - supponendo di poter ricordare e successivamente invertire l'offset O e i byte N, utilizzare questo metodo oltre a una buona password per ingannare il software forense e mantenere la negabilità plausibile nello scenario in cui viene costretto a rivelare il la password?

UPDATE

Spiacente, quello che intendo utilizzare è la crittografia integrata di 7zip AES-256 in combinazione con la crittografia dell'intestazione.

La mia domanda riguardava (deliberatamente) l'alterazione dell'offset di un archivio 7zip crittografato e se la bruteforcing della password fosse addirittura fattibile senza ricostruire gli N byte modificati all'offset O.

    
posta John G 05.08.2017 - 13:54
fonte

1 risposta

3

Ci sono molte supposizioni nella tua domanda, quindi non credo che una risposta generale sia possibile, ma cercherò di esplorarla un po '.

Presumo che tu abbia crittografato l'archivio utilizzando la modalità standard "protetta da password" incorporata negli strumenti zip. Non sono un esperto del formato di file zip, ma sembra non esiste uno standard per quale cifrario usare; RC4 (codifica stream) e DES , 3DES e AES (cifrari a blocchi) sono tutte scelte comuni. Per rispondere a questa domanda, avremo bisogno di esplorare il funzionamento dei codici di crittografia.

Stream Cipher

RC4 è un codice di flusso, che in base a wikipedia , funziona in questo modo:

A stream cipher makes use of a much smaller and more convenient key such as 128 bits. Based on this key, it generates a pseudorandom keystream which can be combined with the plaintext digits in a similar fashion to the one-time pad.

Non ho mai studiato RC4 , ma la mia comprensione è che la crittografia viene eseguita un byte alla volta eseguendo XOR un byte del keystream con un byte del testo in chiaro.

Questo significa che, supponendo che tu conosca la chiave, i 5 byte che hai stravolto verranno decrittografati ed essere irrecuperabili, ma tutti i byte prima di esso e tutti i byte dopo la decifrazione.

Crittografi

I codici a blocchi funzionano in modo completamente diverso dai cifrari dei flussi. È un po 'più difficile da spiegare, ma possiamo guardare alla modalità più comune: blocco di cifratura che concatena con questa immagine da Wikepedia :

Lacosaimportantedanotareècheiltestocifratoperundatobloccodipendedaltestocifratodiquelbloccoedalbloccoprecedente.Quindiquestosicomportaingranpartecomecifraridiflussoinquantoibytechehaimaneggiato(eunbloccodopodiesso)decrittografanoesonoirrecuperabili,matuttiibyteprimadiessoetuttiibytedopoladecodificavannobene.(grazie@dave_thompson_085)

Forzabrutadellapassword

Quindi,ingenerale,amenochenonsiinvertailmangling,ibytemanomessinonsarannorecuperabili,maibyteprimaedopoverrannodecrittati(seibytedopodecomprimonosonounastoriadiversa,grazie@dave_thompson_085,mapoichélacompressioneènonprogettatoperlasicurezza,sonosicurocheunbuonanalistaforensepotrebbeottenereinformazionidaesso).

Nelcontestodiunutentemalintenzionatocheimponelachiavedicrittografia(ovverolapassword),lacrittografiadell'intestazionedizipsemplificaillorolavoro:tuttociòchedevonofareèprovareadecrittografareconpasswordcasualifinchéiprimipochidecrittografanoinunintestazionezipvalida(ol'intestazionedelfiledelprimofilenell'archiviodecodificainun'intestazionedifilevalida).

Cheproblemastaicercandodirisolvere?

Il problema XY

Tornando indietro di un passo, sembra che tu voglia migliorare la crittografia basata su password di ZIP e possibilmente aggiungere una negabilità plausibile inventando una tecnica di offuscamento - o se vuoi essere in grado di capovolgerlo, inventando una tecnica di crittografia.

Come @TTT metti in modo colorato in un commento , non sono sicuro che riuscirai a compromettere in modo convincente la negabilità plausibile sul sistema di crittografia ZIP.

Per quanto riguarda il miglioramento, perché non usare solo AES e buttare via (o non buttare via) la chiave? Oppure, perché non saltare completamente la terribile crittografia basata su password di ZIP e basta eseguire il file .zip con GPG o openssl o qualche altro strumento più moderno che supporti la crittografia a chiave pubblica? (suggerimento: la crittografia nativa di zip era un trucco mal fatto quando è stato scritto, e ora è un hack scaduto. Se vuoi sicurezza, esegui il tuo file zip con uno strumento adeguato piuttosto che cercare di salvare l'hack) .

    
risposta data 05.08.2017 - 18:23
fonte

Leggi altre domande sui tag