Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Gdhsjskksks 01. 02. 2016, 06:30:08
-
Zdravim,
Taka asi hlupa otazka:
Hashe maju problem v koliziach a v pripade ze nejaky hash ich ma lahko a vela tak sa da povazovat za zly, spravne?
A casom md5, sha1 atd.. Proste nie su standardami.
Ok a chapem nadsenie matematikov hladat lepsie a lepsie riesenia ale (a to viem ze kedze to tak nie je tak to asi neni riesenie, skor ma zauima vysvetlenie) co tak proste kombinacia dvoch hashov?
Md5(data)&&Sha1(data)?
Nemusel by potom utocnik hladat taky utok ktory by nasiel koliziu v dvoch na sebe nezavyslych hashovacich algorytmoch? Je vobec mozne najst takuto koliziu?
A nevyhody su ako?
- cas
- dlzka kontrolneho stringu
Je to vsetko?
Dik
-
Co myslis tim "&&"? Spojeni dvou stringu?
V takovem pripade bys zjednodusil (za nejakych podminek) zase hledani originalniho data. Stacilo by najit data tak, ze md5(data) da prvni kus hashe nebo sha(data) da konec hashe. Coz je o dost snazsi nez uloha hledat to ciste pro sha(data).
-
Pokud pro jeden hash máte dvě kolize (dva různé vstupy), ještě to není takový problém. Problém pro hashovací funkci je hlavně to, když pro daný hash dokážete generovat libovolný počet vstupů. Například když budete mít v PDF souboru fakturu a ten soubor bude elektronicky podepsaný, asi vám nebude moc vadit, když někdo najde jeden jiný soubor, který povede na stejný hash – protože ten jiný soubor s vysokou pravděpodobností nebude mít žádný rozumný formát, bude to prostě jen náhodná změť znaků. Pokud ale někdo umí ten PDF soubor vzít, doplnit k částce zprava tři nuly, na nějaké nezajímavé místo v něm schovat „náhodné“ znaky a ty vybrat tak, aby mu hash souboru zase seděl, máte problém.
MD5 je už určitě prolomena tím druhým způsobem, tj. k danému hashi je možné vygenerovat na přání libovolný počet kolizí. A SHA-1 je jen o kousek pozadu, ale myslím, že už praktické útoky také existují. Takže ten váš postup bezpečnost nijak zásadně nezvyšuje. Funguje to podobně, jako kdybyste hash udělal třeba tak, že uděláte MD5 hash dokumentu, pak k dokumentu připojíte nulový bajt a znovu spočítáte MD5 hash, a spojíte tyhle dva hashe. Útočníkovi tím sice poněkud ztížíte práci, ale je to ztížení nepodstatné – útok mu bude trvat třeba dvakrát nebo desetkrát nebo klidně i tisíckrát déle. Jenže to je málo, vy mu útok potřebujete zkomplikovat ne násobky, ale mocninami.
Smysl by to mělo někde, kde na tom hashi zas tak moc nezáleží, třeba při přenosu souborů. Jenže proč to dělat, když tady už dlouho máme SHA-2, která je zatím bezpečná? A matematici jsou zatím docela napřed, takže se momentálně nemusíme bát, že bychom neměli k dispozici dostatečně silný hashovací algoritmus a bylo nutné se uchylovat k takovýmhle pseudořešením, o kterých nic nevíme.
-
Pokud pro jeden hash máte dvě kolize (dva různé vstupy), ještě to není takový problém. Problém pro hashovací funkci je hlavně to, když pro daný hash dokážete generovat libovolný počet vstupů. Například když budete mít v PDF souboru fakturu a ten soubor bude elektronicky podepsaný, asi vám nebude moc vadit, když někdo najde jeden jiný soubor, který povede na stejný hash – protože ten jiný soubor s vysokou pravděpodobností nebude mít žádný rozumný formát, bude to prostě jen náhodná změť znaků. Pokud ale někdo umí ten PDF soubor vzít, doplnit k částce zprava tři nuly, na nějaké nezajímavé místo v něm schovat „náhodné“ znaky a ty vybrat tak, aby mu hash souboru zase seděl, máte problém.
MD5 je už určitě prolomena tím druhým způsobem, tj. k danému hashi je možné vygenerovat na přání libovolný počet kolizí. A SHA-1 je jen o kousek pozadu, ale myslím, že už praktické útoky také existují. Takže ten váš postup bezpečnost nijak zásadně nezvyšuje. Funguje to podobně, jako kdybyste hash udělal třeba tak, že uděláte MD5 hash dokumentu, pak k dokumentu připojíte nulový bajt a znovu spočítáte MD5 hash, a spojíte tyhle dva hashe. Útočníkovi tím sice poněkud ztížíte práci, ale je to ztížení nepodstatné – útok mu bude trvat třeba dvakrát nebo desetkrát nebo klidně i tisíckrát déle. Jenže to je málo, vy mu útok potřebujete zkomplikovat ne násobky, ale mocninami.
Smysl by to mělo někde, kde na tom hashi zas tak moc nezáleží, třeba při přenosu souborů. Jenže proč to dělat, když tady už dlouho máme SHA-2, která je zatím bezpečná? A matematici jsou zatím docela napřed, takže se momentálně nemusíme bát, že bychom neměli k dispozici dostatečně silný hashovací algoritmus a bylo nutné se uchylovat k takovýmhle pseudořešením, o kterých nic nevíme.
No to je zase ale krávovina co jste napsal...
Můžete mi vysvětlit příklad útoku, kdy na třeba vámi zmiňovanou PDF fakturu provedu útok tak, že pak bude sedět předem vytvořený MD5 i SHA1 hash?
Tazatel totiž přesně uhodil hřebíček na hlavičku. Spočítáte-li 2 různé typy hashů pro konkrétní soubor je pak nemožné na něj provést útok tak, aby oba hashe seděly. Buď bude po útoku sedět jeden nebo druhý, ale nikoli oba.
-
ByCzech:Dvě haše ti sice radikálně sníží počet kolizí, ale principiálně ty kolize tam pořád budou a pokud je umím efektivně generovat množiny kolizních hašů, tak není zas tak takový problém najít jejich průnik.
PS: A doporučoval bych Ti být méně arogantní, když evidentně o věci zas tolik nevíš.
-
Kolize nejsou jediny problem, ktery muze u hashovani nastat!
-
Dělal jsem úpravy jednoto webu a tam do administarce bylo toto:
md5(sha(md5(heslo)))
Jen tak jsem si na to vzpomel :D
-
To je nějaký teoretická otázka, nebo to chceš někde využit? Pokud za b/, tak bych doporučil nevynalézat rovnák na vohejbák a použít aktuálně bezpečný hashovací algoritmus. ::)
-
ByCzech:Dvě haše ti sice radikálně sníží počet kolizí, ale principiálně ty kolize tam pořád budou a pokud je umím efektivně generovat množiny kolizních hašů, tak není zas tak takový problém najít jejich průnik.
PS: A doporučoval bych Ti být méně arogantní, když evidentně o věci zas tolik nevíš.
Prosím tedy ukažte útok nebo pošlete informace které to potvrzují, pokud tvrdíte, kolize jsou.
PS: Pokud můj příspěvek vyzněl arogantně, omlouvám se, nebyl tak myšlen.
-
Dělal jsem úpravy jednoto webu a tam do administarce bylo toto:
md5(sha(md5(heslo)))
Jen tak jsem si na to vzpomel :D
A na prvni pohled to vypada jako dobrej napad, co? :-D
-
Dělal jsem úpravy jednoto webu a tam do administarce bylo toto:
md5(sha(md5(heslo)))
Jen tak jsem si na to vzpomel :D
A na prvni pohled to vypada jako dobrej napad, co? :-D
To ale s dotazem nesouvisí, ne? Já dotaz pochopil tak, že se spočítají 2 nezávislé hashe nad danými daty, ne že se udělá hash hashe...
-
Dělal jsem úpravy jednoto webu a tam do administarce bylo toto:
md5(sha(md5(heslo)))
Jen tak jsem si na to vzpomel :D
A na prvni pohled to vypada jako dobrej napad, co? :-D
To ale s dotazem nesouvisí, ne? Já dotaz pochopil tak, že se spočítají 2 nezávislé hashe nad danými daty, ne že se udělá hash hashe...
Ja to taky tak pochopil, ale to spis spekuluji, co vlastne Gdhsjskksks myslel tim &&
-
Není to dobrý nápad
Viz: http://crypto-world.info/klima/2005/cryptofest_2005.htm#_Toc98987112
-
Prosím tedy ukažte útok nebo pošlete informace které to potvrzují, pokud tvrdíte, kolize jsou.
Před deseti lety bylo možné kolize MD5 na běžném notebooku generovat v řádu minut (http://www.root.cz/clanky/nalezani-kolizi-md5-hracka-pro-notebook/).
-
Prosím tedy ukažte útok nebo pošlete informace které to potvrzují, pokud tvrdíte, kolize jsou.
Před deseti lety bylo možné kolize MD5 na běžném notebooku generovat v řádu minut (http://www.root.cz/clanky/nalezani-kolizi-md5-hracka-pro-notebook/).
Já chci vidět útok na soubor, který bude mít předem spočítaný MD5 a SHA1 hash a po útoku bude soubor změněn a OBA vypočítané hashe budou stejné.
Jsem ochoten vám k tomu zapůjčit i výrazně výkonnější HW než byly notebooky před 10 lety.
-
Trochu si zateoretizuju :)
Není to dobrý nápad
Viz: http://crypto-world.info/klima/2005/cryptofest_2005.htm#_Toc98987112
Mno, v tom paragrafu se mi trochu motá kaskáda a řetězení, ale na začátku je jasně napsáno že u řetězení je složitost o něco více než součet složitosti pro jednotlivé funkce. tj. přidáním(zřetězením) druhé hashovací funkce nedochází ke snížení.
Takže, jestli to chápu správně, dva spojené hashe dávají do budoucna lepší výsledek pokud by došlo k teoretickému fatálnímu prolomení jednoho z hashů, nadruhou stranu při použití jednoho hashe který bude mít velikost výstupu jako ty dva dohromady je teoreticky mnohem těžší najít nějakou kolizi(tady spíš odhaduji, kdyžtak mne někdo opravte). Navíc pokud nebude prolomení fatální(ale spíš jenom takové to částečné zjednodušení jak se čas od času objevuje), jeden velký hash bude nejspíše stále bezpečnější než dva kratší.
-
Pokud existuje riziko prolomení MD5 nebo SHA-1, tak jediným rozumným řešením je použití jiného a lepšího algoritmu.
Byla zde zmíněna sada algoritmů SHA-2. Doporučuji vydat se touto cestou.
-
Já chci vidět útok na soubor, který bude mít předem spočítaný MD5 a SHA1 hash a po útoku bude soubor změněn a OBA vypočítané hashe budou stejné.
Jsem ochoten vám k tomu zapůjčit i výrazně výkonnější HW než byly notebooky před 10 lety.
OK. Na tom, že nedokážeme pro daný hash generovat kolize, mohou záviset hodnoty v řádech třeba desítek milionů amerických dolarů. Potenciálnímu útočníkovi se útok vyplatí tehdy, pokud jeho náklady jsou nižší než ta hodnota. Předpokládám tedy, že jste schopen zapůjčit hardware a potřebné prostředky v hodnotě alespoň jednotek milionů amerických dolarů. (Protože pokud to nedokážete s menším rozpočtem, nebude to znamenat, že by to nedokázal někdo s větším rozpočtem.)
Abych věděl, že tu jen tak neplácáte, předveďte, že máte vůbec nějaký výkon k dispozici. Chcete porovnávat MD5+SHA-1 s čistým SHA-1 – tak předveďte, že máte dostatečný výkon alespoň na výpočet kolizí SHA-1. Máte SHA-1 hash 0d495a55e421d7c352cb0dfb3b9069aa00734bc8 pro vstup Hynek Vilem Jarmila (kódovaný v ASCII), najděte jiný kolizní vstup, který má stejný SHA-1 hash.
Pokud by se vám to náhodou nepodařilo, já to s dovolením nebudu považovat za důkaz toho, že SHA-1 je bezpečná.
-
A na co ten hash potrebujes? Potrebujes bezpecny hash algoritmus anebo funkci pro hash tabulku? Existuji i jine hashvovaci algoritmy, napr FNV.
-
anebo funkci pro hash tabulku
MD5+SHA-1 má 128+160 bitů, to by byla slušná tabulka. Jestli máte tolik místa na disku, nenašel by se tam malilinkatý kousíček volného prostoru pro mne? Že bych si tam zazálohoval celý internet…
-
Zdravim,
Taka asi hlupa otazka:
Hashe maju problem v koliziach a v pripade ze nejaky hash ich ma lahko a vela tak sa da povazovat za zly, spravne?
A casom md5, sha1 atd.. Proste nie su standardami.
Ok a chapem nadsenie matematikov hladat lepsie a lepsie riesenia ale (a to viem ze kedze to tak nie je tak to asi neni riesenie, skor ma zauima vysvetlenie) co tak proste kombinacia dvoch hashov?
Md5(data)&&Sha1(data)?
Nemusel by potom utocnik hladat taky utok ktory by nasiel koliziu v dvoch na sebe nezavyslych hashovacich algorytmoch? Je vobec mozne najst takuto koliziu?
A nevyhody su ako?
- cas
- dlzka kontrolneho stringu
Je to vsetko?
Dik
Ak je kod pristupny(open source, teda aj ked nieje open source mozes pouzit) tak sa pouziva universal hashing. Dvojite hashovanie je ti nanic v praxi stoji ta to viac ako ziskas, pozrel by som sa na universal hashing. Z teorie pravdepodobnosti su algoritmy rovnako bezpecne ale v praxi sa asi ocakava ze pouzivas universal hashing(tj utocnik ma mozno vyhodu). Taktiez ak neheshujes hesla tak 128 bitov je zvacsa moc na kluc. Ak hashujes hesla tak md5 itak nepouzivas. A dvojity hash ti tam vobec nepomoze.
Teda pouziv universal hashing :)
-
Trochu si zateoretizuju :)
Není to dobrý nápad
Viz: http://crypto-world.info/klima/2005/cryptofest_2005.htm#_Toc98987112
Mno, v tom paragrafu se mi trochu motá kaskáda a řetězení, ale na začátku je jasně napsáno že u řetězení je složitost o něco více než součet složitosti pro jednotlivé funkce. tj. přidáním(zřetězením) druhé hashovací funkce nedochází ke snížení.
Takže, jestli to chápu správně, dva spojené hashe dávají do budoucna lepší výsledek pokud by došlo k teoretickému fatálnímu prolomení jednoho z hashů, nadruhou stranu při použití jednoho hashe který bude mít velikost výstupu jako ty dva dohromady je teoreticky mnohem těžší najít nějakou kolizi(tady spíš odhaduji, kdyžtak mne někdo opravte). Navíc pokud nebude prolomení fatální(ale spíš jenom takové to částečné zjednodušení jak se čas od času objevuje), jeden velký hash bude nejspíše stále bezpečnější než dva kratší.
Problem je ked utocnik poznas funkciu. Povedzme ze prva hash funkciu ma O(N) a druha O(N) a povedzme ze to celene je O(3*N). V tomto pripade je v pohode ak mas 2N kolizii v jedhom kosiku (Tj 2N hodnost sa nahashuje na to iste miesto), a mas to rovnako rychle. Co je velmi nepravdepodne ak utocnik nepozna algoritmus co pouzicas (druha moznost je ze hashujes vela hodnot do malo kosikov ale tu ti ziadna hash funkcia nepomoze). Druha hash funkcia je nanic salting spravi to iste z pohladu utocnika(ak nepozna co pouzivas a ak pozna tak universal hashing je cesta) Tj MD5(data +'salt') je rovnako beznecne ako AND dvoch hashov a rychlejsie v kazdom pripade.
-
Máte SHA-1 hash 0d495a55e421d7c352cb0dfb3b9069aa00734bc8 pro vstup Hynek Vilem Jarmila (kódovaný v ASCII), najděte jiný kolizní vstup, který má stejný SHA-1 hash.
Ten SHA-1 hash máte špatně, správně je to pro daný vstup cfc59e2641c7d71f2e47040ad9352d1b98e648f1.
-
https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
Najist to najdes. Otazka je ci ti to za to stoji :)
"Over the course of the competition, some 331,252 users participated by allowing their unused processor cycles to be used for key discovery. After 1,757 days (4.81 years), a participant in Japan discovered the winning key."
-
Ono zakonite overlap musi existovat ked hashujes nekonecne vela stringov do konecneho priestoru (160 bitov), teda je ich nekonecne vela.
-
Já chci vidět útok na soubor, který bude mít předem spočítaný MD5 a SHA1 hash a po útoku bude soubor změněn a OBA vypočítané hashe budou stejné.
Jsem ochoten vám k tomu zapůjčit i výrazně výkonnější HW než byly notebooky před 10 lety.
OK. Na tom, že nedokážeme pro daný hash generovat kolize, mohou záviset hodnoty v řádech třeba desítek milionů amerických dolarů. Potenciálnímu útočníkovi se útok vyplatí tehdy, pokud jeho náklady jsou nižší než ta hodnota. Předpokládám tedy, že jste schopen zapůjčit hardware a potřebné prostředky v hodnotě alespoň jednotek milionů amerických dolarů. (Protože pokud to nedokážete s menším rozpočtem, nebude to znamenat, že by to nedokázal někdo s větším rozpočtem.)
Abych věděl, že tu jen tak neplácáte, předveďte, že máte vůbec nějaký výkon k dispozici. Chcete porovnávat MD5+SHA-1 s čistým SHA-1 – tak předveďte, že máte dostatečný výkon alespoň na výpočet kolizí SHA-1. Máte SHA-1 hash 0d495a55e421d7c352cb0dfb3b9069aa00734bc8 pro vstup Hynek Vilem Jarmila (kódovaný v ASCII), najděte jiný kolizní vstup, který má stejný SHA-1 hash.
Pokud by se vám to náhodou nepodařilo, já to s dovolením nebudu považovat za důkaz toho, že SHA-1 je bezpečná.
Vy to nechápete viďte. Jakýkoli výkon je vám momentálně úplně k ničemu, protože nenajdete možnost kolize takové, která bude pro oba algoritmy stejná. Pokud tvrdíte, že někdo takovou kolizi umí vypočítat, dodejte relevantní podklady, já proto rád zajistím potřebný HW.
-
Vy to nechápete viďte. Jakýkoli výkon je vám momentálně úplně k ničemu, protože nenajdete možnost kolize takové, která bude pro oba algoritmy stejná. Pokud tvrdíte, že někdo takovou kolizi umí vypočítat, dodejte relevantní podklady, já proto rád zajistím potřebný HW.
Vaše tvrzení vychází z předpokladu, že nedokážeme v rozumném času hledat kolize pro dané hashovací funkce. Jenže lidé, kteří tomu rozumí, tenhle předpoklad pro MD5 a SHA-1 už nepovažují za splněný. Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci. To, že by to běžným postupem trvalo nepoužitelně dlouho, je irelevantní – to samé platí i pro MD5 i SHA-1 samotné. Jenže pro MD5 a SHA-1 byly vymyšleny „zkratky“, jak to generování kolizí podstatně urychlit. Nikdo nezkoumal, zda takové zkratky neexistují i pro MD5+SHA-1 – takže je bláhové spoléhat na to, že neexistují.
Původní otázka zněla, proč se MD5+SHA-1 nepoužívá, na to je odpověď jednoduchá – protože tu máme SHA-2 a další moderní hashovací funkce, u kterých víme, jak jsou asi bezpečné. Vedle toho je tu návrh na použití MD5+SHA-1, o jehož bezpečnosti nevíme vůbec nic, za to víme, že ty dvě složky mají slabiny, z toho MD5 vážné, takže o spojení takových prvků si nelze myslet nic dobrého.
Tazatel se možná ptal také na to, proč se další hashovací algoritmy vytvářejí. Proč se v době, kdy MD5 a SHA-1 byly ještě považovány za dost silné udělala soutěž na SHA-2, proč pak byla otevřena soutěž na SHA-3 a hashovací algoritmy vznikají stále nové. Na to je odpověď podobná – kombinaci MD5+SHA-1 nikdo nezkoumal, ale protože ji tvoří dvě oslabené hashovací funkce, dá se očekávat, že i to společné použití bude mít slabiny. A poč by se kryptologové zabývali hledáním praktických děr u něčeho, o čem si myslí, že nejspíš děravé bude, když místo toho mohou raději prověřovat funkce, kterým dnes věří.
-
Tu originalny autor:
(asi by som sa mal uz konecne zaregistrovat)
Kazdopadne - ano dakujem sa skvelu diskusiu, jasne nesiel som vynajst koleso a viem ze su lepsie algoritmy a su super :) mna to len zauimalo.
Co som myslel tym && bolo concatenate dvoch hashov. Nie XOR, ani hash hashu ale proste len dva hashe vedla seba.
Co som tym chcel povedat bolo ako pisali niektory prave to ze, podla mna najst koliziu pre MD5 na fakture ja kludne mozne v rade minut, a mozno aj na SHA-1, ale aby ta KOLIZIA BOLA ROVNAKA pri zmene originalneho vstupu to si neviem predstavit.
A to - to si neviem predstavit :) com chcel len vediet ci mam taku zlu predstavivovst ja :) a niekto vie viac, alebo mam v podstate pravdu, len je to neekonomicke (dva hashe pocitat a spajat -> komplikovanejsie ako jeden dobry) a zbytocne dlhe?.
Priklad:
Vstup ASCI:
oliver
MD5: acae273a5a5c88b46b36d65a25f5f435
SHA-1: c539153ba1f947bd4b6f910263b967c4a0a62357
Moj navrh: acae273a5a5c88b46b36d65a25f5f435c539153ba1f947bd4b6f910263b967c4a0a62357
(proste som ich spojil)
No a otazka je ci je toto bezpecne. Nie som matematik a co to som kukal aj online ale ako sa hladaju prelinajuce sa kolizie dvoch hashovych funkcii mi pride velmi velmi narocne :)
Opat dakujem za diskusiu, mal som len strasne nutkanie sa o to podelit... :)
-
Este raz dakujem za fakt dobre vstupy :) ok suhlasim ze sa tym nikto nezapodieval, a preco aj ano ak:
- su casti teoho napanu povazovane za prelomene
- su stale schopny hladat nove a lepsie funkcie :)
Oki chapem, a dakujem. :)
Som rad ze som aspon nelezal tak uplne mimo ze som bol hodny akurat odpluvnutia :)
-
Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci.
Cite needed. Jirsák řekl, proto to tak musí být :D. Komplex božství?
-
Prosím tedy ukažte útok nebo pošlete informace které to potvrzují, pokud tvrdíte, kolize jsou.
Před deseti lety bylo možné kolize MD5 na běžném notebooku generovat v řádu minut (http://www.root.cz/clanky/nalezani-kolizi-md5-hracka-pro-notebook/).
Já chci vidět útok na soubor, který bude mít předem spočítaný MD5 a SHA1 hash a po útoku bude soubor změněn a OBA vypočítané hashe budou stejné.
Jsem ochoten vám k tomu zapůjčit i výrazně výkonnější HW než byly notebooky před 10 lety.
Ony se tu zaměňují dva různé útoky. To, co uvádíte vy, je snaha k existujícímu souboru vygenerovat klon s jiným obsahem ale stejným hashem. To je skutečně stále velmi obtížné.
Jenže on existuje i jiný typ útoku: vygeneruji vám dva soubory s různým obsahem, které budou mít stejný hash. A tenhle útok je díky kolizím řádově rychlejší. I tady přímo na root.cz o tom byly články s příkladem, jak to zneužít.
Rozdíl je v tom, zda má útočník pod kontrolou jen kopii, nebo i originál. Pokud má k dispozici oboje, tak vygeneruje dva prakticky stejné dokumenty, lišící se klidně jen jediným bitem. A díky kolizím dokáže ke každému přidat správný "bordel" tak, aby měly stejný hash. Nefunguje v případě "bezbordelových" formátů jako je .txt, ale funguje dobře u věcí jako je .pdf, .png apod., protože do nich je možné naložit bordel skrytý oku uživatele.
-
Prosím tedy ukažte útok nebo pošlete informace které to potvrzují, pokud tvrdíte, kolize jsou.
Před deseti lety bylo možné kolize MD5 na běžném notebooku generovat v řádu minut (http://www.root.cz/clanky/nalezani-kolizi-md5-hracka-pro-notebook/).
Já chci vidět útok na soubor, který bude mít předem spočítaný MD5 a SHA1 hash a po útoku bude soubor změněn a OBA vypočítané hashe budou stejné.
Jsem ochoten vám k tomu zapůjčit i výrazně výkonnější HW než byly notebooky před 10 lety.
Ony se tu zaměňují dva různé útoky. To, co uvádíte vy, je snaha k existujícímu souboru vygenerovat klon s jiným obsahem ale stejným hashem. To je skutečně stále velmi obtížné.
Jenže on existuje i jiný typ útoku: vygeneruji vám dva soubory s různým obsahem, které budou mít stejný hash. A tenhle útok je díky kolizím řádově rychlejší. I tady přímo na root.cz o tom byly články s příkladem, jak to zneužít.
Rozdíl je v tom, zda má útočník pod kontrolou jen kopii, nebo i originál. Pokud má k dispozici oboje, tak vygeneruje dva prakticky stejné dokumenty, lišící se klidně jen jediným bitem. A díky kolizím dokáže ke každému přidat správný "bordel" tak, aby měly stejný hash. Nefunguje v případě "bezbordelových" formátů jako je .txt, ale funguje dobře u věcí jako je .pdf, .png apod., protože do nich je možné naložit bordel skrytý oku uživatele.
S tím samozřejmě souhlasím.)
Akorát upravit soubor tak, aby dával smysl a měl oba hashe ze dvou různých hashovacích algoritmů stejné není možné. A nevíme jestli to je zatím nebo to není možné, protože ty matematické funkce nemají v takovém případě průniky. Pokud má někdo jiné informace, sem s nimi (Jirsák ne, tomu to je jasné i bez relevantních informací).
-
Co som tym chcel povedat bolo ako pisali niektory prave to ze, podla mna najst koliziu pre MD5 na fakture ja kludne mozne v rade minut, a mozno aj na SHA-1, ale aby ta KOLIZIA BOLA ROVNAKA pri zmene originalneho vstupu to si neviem predstavit.
A to - to si neviem predstavit :) com chcel len vediet ci mam taku zlu predstavivovst ja :) a niekto vie viac, alebo mam v podstate pravdu, len je to neekonomicke (dva hashe pocitat a spajat -> komplikovanejsie ako jeden dobry) a zbytocne dlhe?.
To si nikdo neuměl představit ani u MD5 nebo SHA-1 – protože řešení hrubou silou pořád znamená otestovat nepředstavitelný počet vstupních dokumentů, než se trefíte do takového, který bude mít stejný hash. Jenže se ukázalo, že není nutné to řešit hrubou silou, že jsou v algoritmech chyby, které umožňují „zkratky“ – umožňují generovat vstupní dokumenty tak, že je vyšší pravděpodobnost, že se trefíte do správného hashe. Samozřejmě je možné, že ty „zkratky“ pro MD5 a SHA-1 jsou navzájem nekompatibilní, že nedokážete generovat vstupní dokumenty, u kterých bude ta vyšší pravděpodobnost jako pro MD5 tak pro SHA-1. Ale také je možné, že takováhle zkratka společná pro MD5 i SHA-1 existuje. A to nikdo nebude riskovat.
No a otazka je ci je toto bezpecne. Nie som matematik a co to som kukal aj online ale ako sa hladaju prelinajuce sa kolizie dvoch hashovych funkcii mi pride velmi velmi narocne :)
Hashovací funkce musí být zaručeně bezpečné na několik let dopředu. Takže u nich neplatí, že pokud není znám žádný prakticky proveditelný útok, jsou považovány za bezpečné – naopak, už jenom pokud panuje podezření, že by mohl existovat nějaký teoretický útok, ta funkce je označena za slabou a je doporučeno přestat ji používat. Přesně to se stalo s MD5 i SHA-1 – ty byly nejprve označeny za slabé a bylo doporučeno přestat je používat, teprve po té byly představeny teoretické koncepty útoků, a na konec praktické útoky. Přičemž u MD5 jsou praktické útoky známy už dost dlouho. U SHA-1 bylo známo oslabení od roku 2005 (pořád to ale bylo málo na provedení praktických útoků), proto byl např. v ČR naplánován přechod na SHA-2 nejpozději k roku 2010, zprávy o tom, že by útok na SHA-1 mohl být prakticky proveditelný jsou až z roku 2015.
Nebo-li praktický útok proti SHA-1 je i dnes velmi náročný a těžko představitelný, přesto se SHA-1 (právem) hromadně opouští. Protože už se SHA-1 nedá věřit. A stejné je to s vaší kombinací MD5+SHA-1 – dnes je takový útok těžko představitelný a pravděpodobně je zatím neproveditelný. Jenže ty dvě výchozí funkce jsou považovány za slabé, tím pádem na nich nikdo nebude stavět něco, co by mělo odolat třeba deset patnáct let.
Nebo si to zkuste představit úplně jinak. Máte dva shnilé pilíře, ani jeden z nich už nedokáže unést most sám o sobě. Můžete je spojit do jednoho a nemáte žádnou konkrétní informaci o tom, že tohle spojení by most neuneslo. A vedle toho máte pilíř, u kterého víte, že shnilý není. Budete věnovat energii na ověření toho, zda most s tím spojením dvou shnilých pilířů opravdu nespadne, nebo ji radši budete věnovat tomu, abyste prověřil, že ten pilíř, který není shnilý, je opravdu v pořádku?
-
Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci.
Cite needed. Jirsák řekl, proto to tak musí být :D. Komplex božství?
To triviálně plyne z definice hashovací funkce. Hashovací funkce má na vstupu nekonečnou množinu potenciálních vstupů, na výstupu je konečná množina všech možných hashů dané funkce, její maximální možná velikost je jedním z podstatných znaků dané hashovací funkce (např. u MD5 je to 2128, u SHA-1 2160). Je zřejmé, že při mapování z nekonečné množiny na množinu konečnou musí docházet ke kolizím, dokonce těch kolizí je nekonečné množství.
To, že při nekonečném množství vstupů dostanete na výstupu hashovací funkce kolize, je tak základní znalost, že pokud ji nevíte, nemá vůbec smysl, abyste se do nějaké diskuse o hashovacích funkcích pouštěl.
-
Když dokážete generovat libovolný počet kolizí, je jasné, že mezi těmi kolizemi budou i takové, které mají stejný hash pro jinou hashovací funkci.
Cite needed. Jirsák řekl, proto to tak musí být :D. Komplex božství?
To triviálně plyne z definice hashovací funkce. Hashovací funkce má na vstupu nekonečnou množinu potenciálních vstupů, na výstupu je konečná množina všech možných hashů dané funkce, její maximální možná velikost je jedním z podstatných znaků dané hashovací funkce (např. u MD5 je to 2128, u SHA-1 2160). Je zřejmé, že při mapování z nekonečné množiny na množinu konečnou musí docházet ke kolizím, dokonce těch kolizí je nekonečné množství.
To, že při nekonečném množství vstupů dostanete na výstupu hashovací funkce kolize, je tak základní znalost, že pokud ji nevíte, nemá vůbec smysl, abyste se do nějaké diskuse o hashovacích funkcích pouštěl.
Ciste teoreticky: dusledek to neni. Muzes generovat kolize pro nejakou podmnozinu hodnot hashovaci funkce a nikde neni receno, ze ta podmnozina bude mit neprazdny prunik s mnozinou hodnot jine hashovaci funkce. (Prakticky to samozrejme pravda je, protoze hashovaci funkce maji i jine vlastnosti.)
-
nevíme jestli to je zatím
Což je dostatečný důvod, proč to nepoužívat. Po roce 2005 také nikdo nevěděl, zda oslabení SHA-1 „o pár bitů“ je konečné, nebo jestli se podaří ho prolomit dál. Ale už ta znalost oslabení, které bylo nedostatečné pro praktický útok, stačilo k tomu, aby byla SHA-1 zavržena.
nebo to není možné, protože ty matematické funkce nemají v takovém případě průniky
To by byly hodně špatné hashovací funkce, kdyby pro nekonečně mnoho vstupů nedávaly náhodně rozložené výstupy, ale takové výstupy, aby se to „nepotkalo“ s tou druhou hashovací funkcí.
-
> Ale také je možné, že takováhle zkratka společná pro MD5 i SHA-1 existuje.
MD5 i SHA-1 (i přes různá jména) jsou ze stejné rodiny hashovacích funkcí.
-
nevíme jestli to je zatím
Což je dostatečný důvod, proč to nepoužívat. Po roce 2005 také nikdo nevěděl, zda oslabení SHA-1 „o pár bitů“ je konečné, nebo jestli se podaří ho prolomit dál. Ale už ta znalost oslabení, které bylo nedostatečné pro praktický útok, stačilo k tomu, aby byla SHA-1 zavržena.
nebo to není možné, protože ty matematické funkce nemají v takovém případě průniky
To by byly hodně špatné hashovací funkce, kdyby pro nekonečně mnoho vstupů nedávaly náhodně rozložené výstupy, ale takové výstupy, aby se to „nepotkalo“ s tou druhou hashovací funkcí.
Už vidím jak to nekonečno budete řešit :D... A vo tom to je. Ukažte jinak jsou to jen plky.
-
Už vidím jak to nekonečno budete řešit :D... A vo tom to je. Ukažte jinak jsou to jen plky.
Klidně si dál používejte SHA-1 s odůvodněním, že na svém domácím počítači nedokážete vygenerovat kolizi, tím pádem je to bezpečné. Odborníci na kryptografii mají na kryptografické hashovací funkce přeci jen o něco vyšší nároky, než to, co zvládne či nezvládne vaše pécéčko.
-
Už vidím jak to nekonečno budete řešit :D... A vo tom to je. Ukažte jinak jsou to jen plky.
Klidně si dál používejte SHA-1 s odůvodněním, že na svém domácím počítači nedokážete vygenerovat kolizi, tím pádem je to bezpečné. Odborníci na kryptografii mají na kryptografické hashovací funkce přeci jen o něco vyšší nároky, než to, co zvládne či nezvládne vaše pécéčko.
Blik! My se tu bavíme o něčem jiném, víte to?
-
My se tu bavíme o něčem jiném, víte to?
Nebavíme. Váš argument „na mém počítači kolize nevygeneruji, tudíž je to bezpečná hashovací funkce“ přece musí platit úplně stejně pro SHA-1 jako pro MD5+SHA-1.
-
My se tu bavíme o něčem jiném, víte to?
Nebavíme. Váš argument „na mém počítači kolize nevygeneruji, tudíž je to bezpečná hashovací funkce“ přece musí platit úplně stejně pro SHA-1 jako pro MD5+SHA-1.
Tohle jsem nikdy neřekl. Se lhářem a manipulátorem se tímto odmítám bavit.
-
My se tu bavíme o něčem jiném, víte to?
Nebavíme. Váš argument „na mém počítači kolize nevygeneruji, tudíž je to bezpečná hashovací funkce“ přece musí platit úplně stejně pro SHA-1 jako pro MD5+SHA-1.
Tohle jsem nikdy neřekl. Se lhářem a manipulátorem se tímto odmítám bavit.
Tak co tedy chcete dokázat tím svým „Ukažte jinak jsou to jen plky“ nebo „pokud tvrdíte, že někdo takovou kolizi umí vypočítat, dodejte relevantní podklady, já proto rád zajistím potřebný HW“? Myslel jsem, že chcete předvést výpočet těch kolizí.
-
Ondřej Surý: vy ste dal pomerne pekny koment - ze su z podobnej rodiny hashovacich funkcii a toto je nieco co ma zaujima, tieto rodiny. Ze ci je vobec mozne aby mali rovnake prieniky.
Inak teraz ma napadla mozno este debilnejsia otazka k tym hashom.
Je mi jasne ze sa da pridavat bordel (a odoberat, aj ked to je uz tahsie "asi") aby boli kolizie, preco sa o danom dokumente nepusti nejake info ktore neni hashovane, pomerne jenoznacne, a nikto tam nic moc nepomeni?
Co tak pocet bitov HEX? Tam si uz fakt neviem predstavit co by s tym kto narobil...
[input].MD5 + "[input].lenghtInHEX
A keby sme chceli byt uz uplny zialenci tak este k tomu to SHA-1 ....
A najst koliziu, pre input X, kde je znama jeho fixna dlzka MD5 a SHA-1 to by som si kukol :D
Preto ma to napadlo ze niekto pisal ze pri nekonecnom moznosti INPUTU je aj nekonecna moznost kolizii (ok to znie fakt nebezpecne) ale takto by sme input obmedzili na jeho dlzku (pridavat nemoze, uberat nemoze, mozes iba "menit")... A tam by to uz nemuselo byt take easy ani na "silnejsom HW"
A pritom taka blbost... :)
-
Je mi jasne ze sa da pridavat bordel (a odoberat, aj ked to je uz tahsie "asi") aby boli kolizie, preco sa o danom dokumente nepusti nejake info ktore neni hashovane, pomerne jenoznacne, a nikto tam nic moc nepomeni?
Co tak pocet bitov HEX? Tam si uz fakt neviem predstavit co by s tym kto narobil...
[input].MD5 + "[input].lenghtInHEX
Algoritmus MD5 neznám dopodrobna, ale domnívám se, že délka vstupního stringu do něj také vstupuje.
Na kvalitě SHA-1 stojí a padá celý Git. Takže pokud někomu nestačí SHA-1, může jít do SHA-2.
-
Jasne ze dlzka do MD5 vstupuje :) neviem si realne predstavit ze by do nejakeho algorythmu dlzka nevstupovala (ale mozete ma prekvapit) ide o to ze tu dlzku by som posielal dalej NEHASHOVANU aby sa snou nedalo manipulovat :-) o to ide aby file mal prosiste urcity pocet bitov a tym to hasne.
-
Je mi jasne ze sa da pridavat bordel (a odoberat, aj ked to je uz tahsie "asi") aby boli kolizie, preco sa o danom dokumente nepusti nejake info ktore neni hashovane, pomerne jenoznacne, a nikto tam nic moc nepomeni?
Hashovací funkce bere na vstupu libovolnou posloupnost bajtů, na výstupu je přesně daný počet bajtů (šlo by to obecně i s bity, ale dnes se prakticky používají jen funkce, kde je počet bitů zaokrouhlen na bajty). Jakým způsobem se s tím dál pracuje, jak ten hash uložíte atd., to už je záležitost konkrétní implementace.
Proti útokům typu „tady je dokument, k němu chci jiný se stejným hashem“ by kontrola délky souboru byla většinou docela účinná obrana, proti útoku typu „útočník vytvoří jeden dokument, nechá ho podepsat, a pak k hashi předloží druhý“ by to tak slavné nebylo.
Ale hlavně je zbytečné vymýšlet pochybné obezličky k používání slabých hashovacích funkcí, které budou fungovat jen za specifických podmínek, když máme k dispozici dostatečně silné hashovací funkce.
-
Udana delka skoro zadnou bezpecnost navic neprinasi: http://www.x-ways.net/md5collision.html
-
anebo funkci pro hash tabulku
MD5+SHA-1 má 128+160 bitů, to by byla slušná tabulka. Jestli máte tolik místa na disku, nenašel by se tam malilinkatý kousíček volného prostoru pro mne? Že bych si tam zazálohoval celý internet…
Zni to jako blbost, ale presne takova je realita. Lidi jsou tak zblbli ze vsech tech clanku o bezpecnosti, ze se bezne pouziva MD5 anebo SHA-1 pro hashing. Staci vzit jen par signifikantnich bajtu.
-
Co tak pocet bitov HEX? Tam si uz fakt neviem predstavit co by s tym kto narobil...
[input].MD5 + "[input].lenghtInHEX
A keby sme chceli byt uz uplny zialenci tak este k tomu to SHA-1 ....
A najst koliziu, pre input X, kde je znama jeho fixna dlzka MD5 a SHA-1 to by som si kukol :D
Preto ma to napadlo ze niekto pisal ze pri nekonecnom moznosti INPUTU je aj nekonecna moznost kolizii (ok to znie fakt nebezpecne) ale takto by sme input obmedzili na jeho dlzku (pridavat nemoze, uberat nemoze, mozes iba "menit")... A tam by to uz nemuselo byt take easy ani na "silnejsom HW"
A pritom taka blbost... :)
Uvažuješ velmi správně. Přesně tohle doporučuji pro ověřování dat, když např. není možné použít novější hash funkci. Když vím 2 různé typy hashů a k tomu délku dat, těžko někdo bude schopen vyrobit jiný soubor, který by měl tyto 3 prvky společné při jiném obsahu.
-
Co tak pocet bitov HEX? Tam si uz fakt neviem predstavit co by s tym kto narobil...
[input].MD5 + "[input].lenghtInHEX
A keby sme chceli byt uz uplny zialenci tak este k tomu to SHA-1 ....
A najst koliziu, pre input X, kde je znama jeho fixna dlzka MD5 a SHA-1 to by som si kukol :D
Preto ma to napadlo ze niekto pisal ze pri nekonecnom moznosti INPUTU je aj nekonecna moznost kolizii (ok to znie fakt nebezpecne) ale takto by sme input obmedzili na jeho dlzku (pridavat nemoze, uberat nemoze, mozes iba "menit")... A tam by to uz nemuselo byt take easy ani na "silnejsom HW"
A pritom taka blbost... :)
Uvažuješ velmi správně. Přesně tohle doporučuji pro ověřování dat, když např. není možné použít novější hash funkci. Když vím 2 různé typy hashů a k tomu délku dat, těžko někdo bude schopen vyrobit jiný soubor, který by měl tyto 3 prvky společné při jiném obsahu.
Jak uz tu padlo, tak to nijak zvlast bezpecnost nezlepsuje.
-
Pro ty, kteří pochybují nad kvalitou MD5 i SHA-1: Zkuste si jen tak cvičně prolomit CRC32. Všichni víme, že to jde, ale už málokdo tuší, kolik to dá práce než doladíme změněný dokument tak, aby CRC sedělo a přitom to nebylo nijak nápadné.
A pak si uvědomte, že MD5 a výše jsou o mnoho řádů lepší...
-
Pro ty, kteří pochybují nad kvalitou MD5 i SHA-1: Zkuste si jen tak cvičně prolomit CRC32. Všichni víme, že to jde, ale už málokdo tuší, kolik to dá práce než doladíme změněný dokument tak, aby CRC sedělo a přitom to nebylo nijak nápadné.
A pak si uvědomte, že MD5 a výše jsou o mnoho řádů lepší...
Argumentace vlastni neschopnosti...
-
Pro ty, kteří pochybují nad kvalitou MD5 i SHA-1: Zkuste si jen tak cvičně prolomit CRC32. Všichni víme, že to jde, ale už málokdo tuší, kolik to dá práce než doladíme změněný dokument tak, aby CRC sedělo a přitom to nebylo nijak nápadné.
A pak si uvědomte, že MD5 a výše jsou o mnoho řádů lepší...
A pak si uvědomte, jestli jste ochotni těmhle domácím pokusům svěřit celý svůj bankovní účet.
Kryptografie má bohužel tu nevýhodu, že je obrovský prostor mezi tím, co lze chápat „selským rozumem“ a vyzkoušet si doma, a co je profesionální použití. Když bude mít někdo v domácí databázi problém s deseti tisíci záznamy, asi celkem bez problémů představí, že může existovat databáze s deseti miliony záznamů. Když má někdo doma 10 TB filmů, asi si dokáže představit 1 TB (!) firemní diskové pole. Ale v kryptografii jsou to pokusy s prvočísly 13 a 17 a zkoušení kombinací CRC16 hrubou silou, pak dlouho dlouho dlouho nebezpečno, a pak teprve bezpečná kryptografie. To, že SHA-1 by měla v ideálním případě sílu 280, ale jsou známy útoky oslabující ji na někde kolem 255, se opravdu těžko představuje, zvlášť když je to pořád ještě za hranicí toho, co by si někdo jen tak vyzkoušel pro dobrý pocit z toho, že prakticky prolomil SHA-1.
-
Orig autor: dakujem pani za skvelu diskusiu :-) aj vdaka vam som si co to nasiel na nete a docital sa super inputy :-)
-
Je mi jasne ze sa da pridavat bordel (a odoberat, aj ked to je uz tahsie "asi") aby boli kolizie, preco sa o danom dokumente nepusti nejake info ktore neni hashovane, pomerne jenoznacne, a nikto tam nic moc nepomeni?
Co tak pocet bitov HEX? Tam si uz fakt neviem predstavit co by s tym kto narobil...
[input].MD5 + "[input].lenghtInHEX
Algoritmus MD5 neznám dopodrobna, ale domnívám se, že délka vstupního stringu do něj také vstupuje.
"neznám dopodrobna, ale domnívám se" to je prostě super formulace! Nedala by se na tomto přístupu postavit nějaká alternativní varianta kryptografie? ;D
-
Pokud chcete něco SUPER utajit, vytvořte si vlastní algoritmus, který není znám. Např. mezi byte jednoho hashe občas někam vsunout byte jiného hashe... Pokud utočník vůbec nebude vědět o co jde, určitě to nedá...
Z druhé strany dnes nemá moc logiku vůbec hash používat. Dokument je možné zakryptovat tajným klíčem celý a na druhé straně dekryptovat. Žádné kolizní dokumenty nebudou existovat.... Dnešní výpočetní výkon i přenosové kapacity to umožˇnují. Jak prosté....
-
Pokud chcete něco SUPER utajit, vytvořte si vlastní algoritmus, který není znám. Např. mezi byte jednoho hashe občas někam vsunout byte jiného hashe... Pokud utočník vůbec nebude vědět o co jde, určitě to nedá...
Tohle je velice hloupý postup, protože bez potřebných znalostí takhle s největší pravděpodobností vytvoří něco velmi děravého. A ten super tajný vlastní algoritmus nejspíš bude to první, co útočník získá.
Z druhé strany dnes nemá moc logiku vůbec hash používat. Dokument je možné zakryptovat tajným klíčem celý a na druhé straně dekryptovat. Žádné kolizní dokumenty nebudou existovat.... Dnešní výpočetní výkon i přenosové kapacity to umožˇnují. Jak prosté....
Takže pokud chci přenést přes síť několikagigový soubor, mám jej přenést minimálně dvakrát, abych si byl jistý, že je správně? Když budu chtít dokument opatřit časovým razítkem, mám ho celý poslat autoritě časových razítek? Když bude na dokumentu více podpisů a více časových razítek, budou se velikosti násobit? Heslo mám serveru také předávat v otevřeném tvaru místo hashe?
-
Pokud chcete něco SUPER utajit, vytvořte si vlastní algoritmus, který není znám. Např. mezi byte jednoho hashe občas někam vsunout byte jiného hashe... Pokud utočník vůbec nebude vědět o co jde, určitě to nedá...
Dve tvrdenia a ja nemôžem súhlasiť ani s jedným
Security through obscurity is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States specifically recommends against this practice: "System security should not depend on the secrecy of the implementation or its components."[1]
https://en.wikipedia.org/wiki/Security_through_obscurity
Z druhé strany dnes nemá moc logiku vůbec hash používat. Dokument je možné zakryptovat tajným klíčem celý a na druhé straně dekryptovat. Žádné kolizní dokumenty nebudou existovat.... Dnešní výpočetní výkon i přenosové kapacity to umožˇnují. Jak prosté....
Ako vtip do silvestrovského programu dobré, ale inak mi idú zimomriavky po chrbte keď si predstavím, že by si toto myslel niektorý môj kolega
-
Kazdopadne - ano dakujem sa skvelu diskusiu, jasne nesiel som vynajst koleso a viem ze su lepsie algoritmy a su super :) mna to len zauimalo.
Co som myslel tym && bolo concatenate dvoch hashov. Nie XOR, ani hash hashu ale proste len dva hashe vedla seba.
Jak zaznělo velmi rychle, problém je, že útočník dostane jak MD5 tak SHA. To už se mi jako lepší jeví ten XOR, i když u něj je problém s nestejnými délkami hashe. Stejně jako další doporučuji, je-li to možné, raději sáhnout po jiné funkci jako SHA-2 či SHA-3.
Záleží i na tom, co hodláte hashovat - pro hesla je SHA naprosto nevhodná, pro zdrojáky se hodí velice.
-
To už se mi jako lepší jeví ten XOR
S XORem těch hashů jste to ještě oslabil. Když ty hashe dáte vedle sebe, bude mít hash1 na pozici n bit třeba 1 a hash2 na pozici n bit třeba 0. A útočník musí trefit takový vstupní dokument, který tyhle dva bity trefí úplně stejně (a ostatní bity samozřejmě také). Pokud uděláte XOR, útočníkovi stačí, když trefí takový vstupní dokument, že ve výsledku bude mít na n-té pozici hash1 také 1 a hash2 také 0, ale přípustná je i opačná kombinace, tedy hash1 0 a hash2 1. Pro dva stejně dlouhé hashe byste tím složitost efektivně zkrátil na polovinu, pro různě dlouhé hashe byste asi kratší hash doplnil nulami, XORem byste tedy složitost zkrátil „jenom“ o polovinu délky kratšího hashe.
-
jop to so msa docital hned na zaciatku preto nie XOR :) XOR sa sice zda fajn v skutocnosti to ale ulahcuje
-
S takovymto spojovanim hashovacich fci se poji nekolik problemu - muze dojit k tomu, ze se obe konstrukce vzajemne oslabi (odbocim-li od hashi k sifrovacim fcim, pak podobnou situaci muzu najit napr. u vetveni v ramci systemu zalozeneho na kvadratickych polynomech nad konecnym telesem), takovato skladani se navic hure analyzuji a vykon take neni uplne idealni. Suma sumarum nejde ani tak o pravdepodobnost nalezeni kolize jako spise o disproporci mezi "ocekavanou" a realnou pravdepodobnosti (omlouvam se predem za spise heuristicke odvozeni).
Co se tyce navrhu z kategorie "security through obscurity" - doporucuji si udelat tragikomicky vecer nad Mifare Classic (Crypto 1), A5/1 nebo A5/2 a jako perlu vecera zvolit WPS. (Ale je stejne fakt, ze muzeme hucet do lidi jak chceme, ale vzdy se najde najaky magor, ktery si rekne, ze nikdo neprolomi dvojityho Caesara.)
P.S.: Dokumenty umoznuji do sebe hazet relativne velke mnozstvi metadat, coz muze byt dobry prostor pro bruteforcing (napr. dam-li nejaka data za trailer bity obrazku, pak si tam muzu hazet, co chci a nic to neovlivni)
-
Jasne ze dlzka do MD5 vstupuje :) neviem si realne predstavit ze by do nejakeho algorythmu dlzka nevstupovala (ale mozete ma prekvapit) ide o to ze tu dlzku by som posielal dalej NEHASHOVANU aby sa snou nedalo manipulovat :-) o to ide aby file mal prosiste urcity pocet bitov a tym to hasne.
To nepomůže, často ti jde o útoky na zprávy, které obsahují smetí. Například PDF dokument určitě půjde o pár set bajtů zoptimalizovat (snížení kvality vložených JPEG obrázků o 1 %…), aby se jinde mohlo zase pár set bajtů doplnit tam, kde to algoritmus pro generování kolizí potřebuje.
S takovymto spojovanim hashovacich fci se poji nekolik problemu - muze dojit k tomu, ze se obe konstrukce vzajemne oslabi
To si nedokážu představit (za předpokladu, že útočník dokument zná, což vypadalo jako předpoklad tazatele). Je mi jasné, že bezpečnost může být stejná, protože třeba někdo najde obecný útok na Merkle–Damgård schéma, které používají obě podobně, ale určitě ne nižší.
Na druhou stranu pro praktického útočníka tu může být jistý obscurity factor - asi dojde k situaci, kdy si budeš moct stáhnout hotový program na generování kolizí v SHA-1, ale ohnout ho, aby pracoval s nějakou custom kombinací SHA-1 a MD5, bude vyžadovat znalost problematiky a nějakou dobu programování. A to se útočníkovi nemusí vyplatit, pokud je to low-profile target.
-
To si nedokážu představit (za předpokladu, že útočník dokument zná, což vypadalo jako předpoklad tazatele). Je mi jasné, že bezpečnost může být stejná, protože třeba někdo najde obecný útok na Merkle–Damgård schéma, které používají obě podobně, ale určitě ne nižší.
Uznavam, ze u hashe pouzivane jako checksum pro znamy dokument je to myslenka na oslabeni dost na hrane (nicmene mohla by byt zavislost mezi mnozinami vyhovujicich plaintextu pro danou cast hashe). Nicmene Merkle–Damgårdova konstrukce by mela byt z hlediska dokazatelne bezpecnosti v poradku za predpokladu, ze pouzita kompresni fce je bezkolizni (MD Veta: zjednodusene -> pokud bych mel kolizi v poslednim kroku, tak z bezkoliznosti fce bych mel kolizi uz o krok drive atd., overeni stejnych delek zalezi na konkretni variante MD).
Obscurity factor je dost rizikovy - muzu byt low-profile target, ale muze se stat, ze nekdo, kdo jim neni, pouziva stejnou metodu. Falesny pocit bezpeci je pak dost zakerna vec.
P.S.: Bezkolizni opet z hlediska teoreticke kryptografie, tzn. nikoliv neexistence kolize, ale obtiznost nalezeni kolize.