[16:35:28]alfa[~]$ md5sum 1 2
87608a1174a5b2a990b929e4a52dc683 1
189490f3dc4b30262d17cd4054110436 2
v 1 a 2 su spravy z clanku
podla clanku uvedene hashe by mali byt rovnake... nie ? medzery som odstranil...
nielenze mi nevysla hash z clanku ale ani niesu rovnake, co robim zle ?
Vlákno názorů k článku
Hašovací funkce MD5 a další prolomeny!
mali by byt rovnake...
Re: mali by byt rovnake...
V tech souborech 1 a 2 jsou ascii stringy nebo primo data s uvadenou ascii reprezentaci ?
Re: mali by byt rovnake...
Vzhledem k tomu, že tam jsou jenom znaky [0-9a-f], tak to budou asi HEX kódy znaků.
Re: mali by byt rovnake...
Jo, a ještě se ty dvouslova musí brát obráceně, jako v little-endian pořadí. Takže když je v tomto článku napsáno 1234ABCD 5678EF09, tak se místo toho veme CDAB341209EF7856 --- četl jsem to v původním článku, ale nezkoušel jsem to.
Re: mali by byt rovnake...
No nejako tak to vyslo aj mne. Tiez sa cudujem preco mi vysli 2 rozdielne MD5 a este k tomu ani jedna z nich nezodpoveda popisu v clanku. Skusal som pre istotu aj PHP funkciu md5() a tam som napodiv dostal zase ine hashe : f6e44db01f60a35bf2794cee6fee575a (a) 54607d90638616b2283638049e936aa5. Takze teraz uz mam 4 rozdielne :-) (resp. ak ratam aj clanok tak 5)
Re: mali by byt rovnake...
Zkoušel jsem to na linuxu pomocí "md5sum" a vyšel mi stejný hash jako vám a rozhodně se neshoduje s článkem.
Re: mali by byt rovnake...
Vlepte každý z kousků hexu do jiného souboru a přečtěte je pomocí
perl -ne 's/\s+//g; print pack('H2', $1) while (s/^(..)//)' vstup > vystup
Pak to funguje.
Re: mali by byt rovnake...
Trošku vydařenější pokus je na:
http://www.md5crk.com/sha0col/
Zkoušel jsem a funguje
Re: mali by byt rovnake...
Tohle mě opravdu děsí. Koukněte na www.md5crk.com a podívejte se jak lze toto zneužít při zabezpečené komunikaci. Např. moje banka používá md5 (https://www.servis24.cz). Docela by mě zajímalo, jak moc je to reálně zneužitelné?!
Re: mali by byt rovnake...
Zneužitelnost je o něco menší, než jen pouhé nalezení kolize. Třeba u zmíněného kernelu je potřeba najít dva rozdílné soubory dat, které půjdou rozbalit, budou stejně dlouhé a navíc bude ten druhý dávat smysl (tj. obsahovat požadovanou (dis)funkci) - tedy aby to mělo alespoň minimální naději na úspěch. To je už netriviální (resp. méně jednoduché, než pouhé nalezení kolize). Stejně tak teoretická možnost, že se mi podaří nechat si u Verisignu podepsat můj veřejný klíč se smysuplnými hodnotami zvolenými díky kolizi tak, že budu následně schopen vyměnit moje údaje za (slovní) identifikaci eBanky (tj. nalezená kolize neohrozí funkčnost veřejného klíče), pak jim unést DNS a nebo pomocí trojského koně spáchat man-in-the-middle attack. Tj. že uživatel bude komunikovat s mojim serverem a bude si myslet, že komunikuje s eBankou (kontrola popisu certifikátu, MD5 a tudíž i zřetězené kontroly uvnitř prohlížeče bude OK) a já (jako man-in-the-middle) budu eBance předávat pozměněné příkazy k úhradě. Poučení pro publikum - vidíte-li použití MD5 jako ověření identity, pak ověřujte i SHA1. Objevení současné kolize dvou rozdílných algoritmů snižuje pravděpodobnost na násobek obou obtížností. BTW: životnost hashovacích funkcí je omezená časově právě kvůli zvyšování výpočetní kapacity a tím reálnosti (snadného) nalezení kolize. Současné nalezení významného ulehčení je vlastně urychlení procesu stárnutí algoritmu.

