Článek
Otevřel jsem malý ZIP v hexadecimálním pohledu a první čtyři bajty byly 50 4B 03 04. Dva prostřední bajty 50 a 4B jsou v ASCII písmena P a K. Není to náhoda: formát ZIP pochází od Phila Katze a společnosti PKWARE. Zároveň ale první čtyři bajty nejsou jen podpis autora - tvoří signaturu lokální hlavičky souboru.
Pak jsem zkusil druhou věc. Do archivu jsem uložil přesně 4096 bajtů známých dat bez komprese a vzal jejich CRC-32. Vyšlo 7D3E2A96. Následně jsem postupně změnil každý jednotlivý bit vzorku - 4096 bajtů krát osm bitů, tedy 32 768 různých jednobitových změn. Ani jediná modifikace v tomto testu neměla stejné CRC-32 jako originál.
Co přesně znamená 50 4B 03 04
Specifikace ZIPu používá pro lokální hlavičku hodnotu 0×04034b50. Když se čtyři bajty zobrazí v pořadí, v jakém jsou v souboru, dostaneme 50 4B 03 04. Library of Congress proto uvádí tuto čtveřici jako typickou signaturu ZIPu a zároveň upozorňuje, že většina ZIPů jí začíná, nikoli nutně úplně všechny možné soubory používající formát.
Po lokální hlavičce následují data daného souboru. Na konci archivu je centrální adresář, který nese informace o uložených položkách. ZIP tedy není jen „stlačený blok“, ale strukturovaný kontejner.
Vlastní test: 4096 bajtů a 32 768 změn
Pro test jsem vytvořil deterministický 4KB vzorek a uložil ho do ZIPu metodou STORE, tedy bez komprese. Samotný archiv měl 4214 bajtů a opravdu začínal 50 4B 03 04. Původní CRC-32 dat bylo 0×7D3E2A96.
Potom skript pro každý ze 4096 bajtů vytvořil osm variant - v každé otočil právě jeden konkrétní bit. U každé varianty se CRC-32 přepočítalo. Výsledek tohoto přesně vymezeného datasetu: 32 768 testovaných jednobitových změn, 0 případů se stejným CRC jako originál.
Tohle není důkaz, že CRC zachytí libovolnou změnu
Tady je důležitá brzda. Výsledek znamená pouze to, co skutečně testuji: v tomto 4KB vzorku žádná jednotlivá změna jednoho bitu nezůstala bez povšimnutí. Není to tvrzení, že CRC-32 odhalí každou možnou kombinaci změn v libovolně velkých datech.
CRC-32 má pouze 32 bitů, tedy konečný počet možných výsledků. Různá data proto mohou mít stejné CRC. Python dokumentace navíc výslovně říká, že CRC-32 není kryptograficky silné a nemá se používat pro autentizaci nebo digitální podpisy.
CRC hlídá náhodné poškození, ne důvěryhodnost autora
V ZIPu je CRC praktické hlavně jako kontrola integrity při poškození dat. Program může po rozbalení znovu spočítat CRC a porovnat ho s hodnotou uloženou v archivu. Když se data cestou náhodně změní, kontrola má velkou šanci problém odhalit.
Ale útočník, který obsah záměrně upraví, může také přepočítat CRC a do archivu uložit novou hodnotu. CRC proto neodpovídá na otázku „kdo tento soubor vytvořil“ ani „mohu autorovi věřit“. K tomu slouží kryptografické podpisy a jiné mechanismy.
Dvě drobnosti v jednom souboru
Čtyři bajty 50 4B 03 04 pomáhají programu poznat začátek lokální struktury ZIPu. CRC-32 zase pomáhá zkontrolovat, že rozbalená data odpovídají tomu, co bylo do archivu uloženo. Jedno je identifikace struktury, druhé kontrolní součet.
A písmena PK jsou pěkná historická stopa. I po desetiletích zůstalo jméno Phila Katze schované v bajtech, které denně vznikají v archivech po celém světě.
Zdroje
