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) .