Stažené soubory s nesedícím md5

[Filip Jirsák (forum)]

Reagoval jsem na vaše tvrzení, že „pořád budete mít u BLAKE3 nesrovnatelně větší jistotu, než u MD5.”

Za předpokladu, že útočník může ovlivnit obsah zdrojového souboru, aby mohl provést útok nalezením kolize, nemáte u MD5 jistotu, že se soubory neliší.

Snažím se říct, že kdyby byla MD5 neprolomená, je MD5 a půlka hashe BLAKE3 srovnatelně dobrá. Ale prolomení MD5 ho totálně degraduje. I když je možný jen útok na kolize prvního řádu, ověřit, že útočník nemůže zmanipulovat zdrojový soubor je extrémně obtížné. Třeba u distribuce softwaru, který používá spousty různých knihoven. Zejména když se postupně spěje k opakovatelným buildům, což útočníkovi v tomto směru paradoxně nahrává.

Máte pro své tvrzení nějaký důvěryhodný zdroj? Ne, že bych to problematiku podrobně sledoval, ale stále mi výsledky hledání hlásí i pro rok 2025 prakticky nedosažitelný second-preimage MD5 attack (dokonce se mi tu někde mihlo, že to nejde ani pro MD4). Pochopitelně se bavíme o běžných velikostech zpráv/souborů. Nikoli „laboratorní” jednotky bajtů.

Máte pravdu. Nepozorně jsem si to přečetl – ty certifikáty nebyly vytvořené jako dvojčata k již existujícím certifikátům, ale útočníci/útočníci si nechali vystavit certifikát, následně v něm změnili některé atributy ale výsledek měl stejný hash, takže na modifikovaném certifikátu byl stále validní podpis CA. Pre-image útok proti MD5 byl navržen v roce 2009, ale zůstává stále jen teoretický kvůli velké výpočetní složitosti. Omlouvám se za mystifikaci.

[Reklama]

[Honza1Ubuntu]

Pokud chci porovnávat jen okometricky, tak je dobré vzít v úvahu i délku výsledného hashe.
Přece jen je rozdíl koukat na řetězce typu (a hledat rozdíl):
CRC32 - B7781039
MD5 - 3d166650cb8991f23a1b9f77b1f4901c
BLAKE3 - 28b5122d0aea9630ba3421baf150fa08ff05d34bf7209575db3056da8fa7f62f

U obou souborů si dáš výsledné hashe do TXT souboru (obě), pak označíš v TXT souboru jeden řetězec a měl by se "rossvítit" i ruhý řetězec, je-li stejný. A pak je jedno, jestli jde o porovnávání 10 nebo 10000 znaků. Porovnávám takto velikosti, hashe, data v určité řádce-úseku, adresy, souřadnice, čísla účtů, emaily a další.

Pokud jednu řádku či slovo ve velkém seznamu v TXT souboru označím, automaticky se v tom texťáku "rosvítí" všechny stejné řetězce. Porovnávat okem byť jen telefonní číslo je otrava.

[Vít Šesták (v6ak)]

Podstatnym kvalitativnim ukazatelem dobreho hashe je, ze i pri zmene byt jednoho bitu, bude cely hash vypada uplne jinak Takze nezalezi na delce.. zmena bude patrna uz z prvnich (ci poslednich) cislic. (ostatne to je princip i zkracovani u git commit hashe)

Bavíme se o náhodné kolizi prvních/posledních pár bytů, nebo o cílené kolizi? Cílenou kolizi pár bytů uděláte hrubou silou. U sedmimístného git commit id máte 4*7 = 28 bitů, to je s brute force hračka, to spočítáte dnes snad i na hodinkách. Pokud můžete měnit něco na konci souboru, dokonce ani nemusíte pokaždé počítat hash od začátku, ale můžete podstatnou část výpočtu sdílet.

BTW, kdysi dávno (tak před 20 lety) jsem narazil na ffp (fuzzy fingerprints), což je nástroj, který generuje klíče, jejichž hashe vypadají vizuálně podobně: https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

[Vít Šesták (v6ak)]

A k pre-image útokům na MD5 jsem našel pár let starou informaci, že jsou zatím prakticky neproveditelné, nejlepší známá možnost je vlastně méně než 25* méně složitá než hrubá síla: https://security.stackexchange.com/a/261417

Reálné útoky se tedy spíš soustředí na to, aby nebylo potřeba najít jiný pre-image, ale jen obyčejnou kolizi. Nevím, jestli je k tomu prakticky použitelná samotná knihovna třetí strany, spíše nějaká binární data jako třeba obrázek. Nebo něco, kam lze skrýt vhodná metadata, aniž by to bylo někomu divné.

[Filip Jirsák (forum)]

Reálné útoky se tedy spíš soustředí na to, aby nebylo potřeba najít jiný pre-image, ale jen obyčejnou kolizi. Nevím, jestli je k tomu prakticky použitelná samotná knihovna třetí strany, spíše nějaká binární data jako třeba obrázek. Nebo něco, kam lze skrýt vhodná metadata, aniž by to bylo někomu divné.

Je úplně jedno, zda to bude obrázek nebo binárka knihovny. Akorát že obrázků z externích zdrojů Nextcloud asi moc nemá, externí knihovny určitě používá.

[Reklama]

[Vít Šesták (v6ak)]

Pokud si tu knihovnu stáhne v binární podobě bez další kontroly, a autor té knihovny (nebo někdo po cestě, třeba CI) se snaží udělat útok, je to problém i s řádnou kontrolou hashů.

Pokud si tu knihovnu kompiluje NextCloud nebo pokud má reproducible build, je zase těžší tam něco smysluplného podstrčit, aniž by to ve zdrojových kódech vypadalo divně. Upravit zdrojový kód tak, aby z kompilátoru vypadla zvolená sekvence dat (pro útočníka v podstatě náhodný blob) na vhodné pozici, není úplně sranda. Nejlépe by to šlo asi nějakým stringem, ale pak nemusí být úplně sranda jeho přítomnost nějak rozumně obhájit. Proto mi obrázky a další data přijdou pro útočníka příhodnější.

[Zdenek Tomes]

Původní otázka: "stáhnu přes wget soubor a nesedí md5"

Kam jsme došli: "md5 je outdated, je snadné () vytvořit jiný soubor se stejným md5, musí se použít XXX nebo YYY, což je free-cool-in a moderní"

Tak evidentně problém s kolizí MD5 původní autor nemá, spíš naopak, že? :-)

[Wasper]

Tak evidentně problém s kolizí MD5 původní autor nemá, spíš naopak, že? :-)

Pardon, že vstupuji tak pozdě, ale opravdu je v celém vlákně řeč o tom, že kontrola MD5 je špatně, protože nějakej hypotetickej útočník, kterej dokáže na webu změnit package.deb tak, aby dosáhl kolize (pamatuji, že pan Klíma předvedl, že je potřeba pro kolizi mít volných 32 bitů padu, kterýma se předchozí změna 32 bitů "srovnala" nebo tak nějak nejlepší útok vypadal), takže magickým způsobem když místo package.deb.md5 tam dáme package.deb.sha384 (předpokládám, že většina diskutujících tuší, proč ne rovnou 512), tak nějakým zázrakem ten samej útočník nedokáže ten *.sha384 prostě přepsat jako tu původni package?

[Filip Jirsák]

Původní otázka: "stáhnu přes wget soubor a nesedí md5"

Kam jsme došli: "md5 je outdated, je snadné () vytvořit jiný soubor se stejným md5, musí se použít XXX nebo YYY, což je free-cool-in a moderní"

Tak evidentně problém s kolizí MD5 původní autor nemá, spíš naopak, že? :-)

Došli jsme k tomu, že lidé, kteří celou tu diskusi nečetli (protože jinak by zjistili, že takovýhle příspěvek už tu byl) svým úplně offtopic komentářem upozorňují, že diskuse je offtopic. Přičemž kdyby si tu diskusi přečetli, věděli by, že to vůbec nevadí protože původní problém byl dávno vyřešen.

Asi budeme potřebovat zavést „stupeň offtopic“, podobně jako se určuje třeba mohutnost množin. Takže už tu máme příspěvky offtopic⁰ příspěvky k vadnému hardwaru, offtopic¹ příspěvky o MD5, dále offtopic² příspěvky o tom, že příspěvky o MD5 jsou offtopic. A pak offtopic^LP příspěvky, z větší části smazané, které jsou offtopic úplně mimo všechny kategorie.

Pardon, že vstupuji tak pozdě, ale opravdu je v celém vlákně řeč o tom, že…

Ne, není.

[Wasper]

Ne, není.

Ale ano, je. Tak, jak to dělají ve zmíněném NextCloudu je naprosto správně a používají daný hash přesně způsobem, kde dává smysl (integrita), a nepoužívají ho tam, kde smysl nedává (gpg pokud se nepletu používá pro signaturu v defaultu sha256, který je k tomu vhodný), stačí číst místo dogmatického svatého boje.)

    Download the .tar.bz2 or .zip archive.
    Check package integrity using MD5 (.tar.bz2 / .zip) or SHA256 (.tar.bz2 / .zip)
    Verify the authenticity via PGP (.tar.bz2 /.zip). The Nextcloud GPG key is here. You can also grab the keys by issueing this command:
    gpg --keyserver keys.openpgp.org --recv-keys 28806A878AE423A28372792ED75899B9A724937A

tl;dr Proti chybě chrání dostatečně prakticky cokoli, nejen md5, ale klidně i half-md4, jen do crc32 bych nešel (1:4miliardy je sice dostatečně malá šance i tak, ale muselo by se vyloučit, že kdekoli, kudy ty data tečou na jakékoli architektuře, není použitej stejnej crc32, jinak by to jen potvrdilo chybu...), pro ověření je potřeba použít kryptograficky silný hash.

[Filip Jirsák (forum)]

Tak, jak to dělají ve zmíněném NextCloudu je naprosto správně

Není. Hash souboru se používá i tak, že si jej stáhnete důvěryhodnou cestou, a samotný soubor už pak můžete stáhnout jakkoli a na závěr jenom ověříte jeho hash.

používají daný hash přesně způsobem, kde dává smysl (integrita)

Použití MD5 v takové situaci stejně smysl nedává, už to tu bylo vysvětleno několikrát.

nepoužívají ho tam, kde smysl nedává

Když někde vystaví GPG klíč, mohou tam úplně stejně vystavit hash (vytvořený neprolomeným algoritmem) a bude to mít úplně stejnou funkci.

tl;dr Proti chybě chrání dostatečně prakticky cokoli, nejen md5, ale klidně i half-md4, jen do crc32 bych nešel (1:4miliardy je sice dostatečně malá šance i tak, ale muselo by se vyloučit, že kdekoli, kudy ty data tečou na jakékoli architektuře, není použitej stejnej crc32, jinak by to jen potvrdilo chybu...), pro ověření je potřeba použít kryptograficky silný hash.

Akorát nedává smysl používat jeden prostředek na zajištění integrity a druhý prostředek na integrity+autenticity, protože integrita+autenticita v sobě integritu zahrnuje.

Je to stejné, jako HTTP vs. HTTPS nebo ifconfig vs iproute2 na Linuxu. Existují situace, kdy technicky nevadí použít HTTP, ifconfig nebo MD5. Akorát že ověření předpokladů, že to stačí, je nesrovnatelně náročnější, než prostě všude používat HTTPS, iproute2 a neprolomené hashovací funkce. Navíc u toho HTTP je aspoň nějaká výhoda oproti HTTPS – menší náročnost na zdroje. Jenže MD5 nemá oproti alternativám vůbec žádnou výhodu – třeba BLAKE3 je i výrazně rychlejší.

Speciálně u Nextcloudu to pak má ještě jeden aspekt. Prezentuje se jako řešení pro bezpečné uložení souborů. Když nějaký neznalý uživatel bude řešit otisky souborů, tak klidně použije MD5 – protože to přece používá i Nextcloud a ti snad problematice rozumí.

Ostatně proto vzniklo celé tohle offtopic vlákno – protože původní tazatel automaticky sáhl po MD5. Ale máme rok 2025, laik by vůbec neměl vědět, co je MD5, nebo by to měl mít zařazené někde u disket jako dávnou minulost. A odborník by se měl podivit, co tam ty .md5 soubory pořád dělají. No a vzhledem k tomu, že to tak stále není, je evidentně nutná osvěta ze strany odborníků.

[LamZelezo]

Tohle vlakno uz davno neni o prenosu souboru, md5 nebo o sha256, ale o neuveritelne neschopnosti nekterych lidi pochopit psany text a jejich naprosto neprijatelne a nelidsky arogantni snaze sproste lhat do oci ostatnim.

[mhepp]

Jirsáku, a teď se s námi poděl, jak tvoje úvahy pomohly vyřešit tazateli problém. Myslím si, že je mu úplně jedno, jestli je MD5 v tomto případě vhodné nebo ne, protože s problémem to nemá nic společného.

Děláš tomuto diskuznímu fóru dost slušnou službu. Bohužel jen medvědí.