Je to doplnění velmi dobré úvahy Milana Keršlágera. Jaká je teda složitost vytvoření dvou různých kernelů se stejnou kontrolou? (Problém vytvoření kolidujícího kernelu k již existujícímu "cizímu" kernelu je mnohařádově složitější úloha) Berme kernel jako libovolný SW, jehož pravost je ověřena otiskem MD5. Číňani ukázali, že s největší pravděpodobností (všichni tomu věří) mohou hledat kolize při libovolném IV. Napíšu dva kernely, vše podstatné je balík SW "na začátku zdrojáku". Liší se jen na konci - jeden třeba končí nějakým komentářem (označme REM), kdežto druhý tam má soft - zadní vrátka. Při hašování u obou kernelů dojdeme až k hranici REM, kde jsou zatím oba kontexty (mezivýsledky hašování) stejné. Tenhle mezivýsledek je vlastně nový IV pro čínskou metodu. Teď teprve budeme hledat vhodný obsah REM a škodlivého kódu v druhém kernelu, které kolidují při tomto IV. Máte pravdu, že je tam mezikrok komprimování, čili úloha je o tento krok složitější. To hlavní - balík softu před rozdílem, má ale stejný komprimovaný začátek i startovní bod pro hledání kolize. Ještě bych se snažil přinutit komprimační program tak, aby něco nekomprimoval. Neznám tar.gz, ale třeba u winzipu to jsou služební hlavičky souborů. Tím lze vytvořit prostor pro variabilní vatu, potřebnou k nalezení kolize. Neříkám, že je to jednoduché, ale takhle bych na to šel.
Taru se to netýká, ten jen balí více souborů do jednoho a pro jeho kompresi si za běhu volá gzip, bzip2, compress nebo něco jiného. Gzip umí ukládat data bez komprese, a snad to i přepíná automaticky (řádek *file_method = STORED; v trees.c).
Každopádně díky tomu, že se volba způsobu komprese týká celého archívu a ne jednotlivých souborů jako u .zip, tak by nárůst délky archivu (pokud by nebyl komprimovaný) byl nápadný.
Tohle je komplikované kompresí. Ale jak je to třeba u Wordového dokumentu?
1) Firma vytvoří smlouvu.
2) Zákazník elektronicky podepíše (podepisuje hash dokumentu, je to tak???)
3) Firma změní dokument a na konec souboru přidá pro Word nečitelné nesmysly, které upravují hash na hodnotu v době podpisu.
Je toto možné udělat jednoduše v řádu hodin??? Objevili Číňani jen metodu jak vytvořit dva nesmysly se stejným md5sum, nebo jak dopočítat k existujícímu dokumentu druhý změněný, tak aby hashe kolidovaly???
Dál k internetovému bankovnictví:
Je možné, aby byl tedy po cestě mezi serverem a klientem změněn např. příkaz k úhradě, dopočítán md5sum a paket znovu šifrován veřejným klíčem banky a odeslán serveru??? Na to neni ani porřeba obstarat stejný certifikát jako má banka ne? Zpět už přece komunikuje banka a ta je důvěryhodná?! Prostě se jen po cestě vytvoří jiný příkaz se stejným md5, jako měl u klienta? Šlo by to???
Poslední věc:
Jestli tomu rozumím, tak prolomení sha-1 by bylo možné dosáhnout také, jen na to zatím nikdo nenašel vhodný algoritmus???
Je možné tedy v případě nalezení JEDNÉ kolize (třeba čistě náhodné), vytvořit právě tento algoritmu fungující obecně???
>Ale jak je to třeba u Wordového dokumentu?
> 1) Firma vytvoří smlouvu.
> 2) Zákazník elektronicky podepíše (podepisuje hash dokumentu, je to tak???)
> 3) Firma změní dokument a na konec souboru přidá pro Word nečitelné nesmysly,které
> upravují hash na hodnotu v době podpisu.
> Je toto možné udělat jednoduše v řádu hodin??? Objevili Číňani jen metodu jak vytvořit dva nesmysly se stejným md5sum, nebo jak dopočítat k existujícímu dokumentu druhý změněný, tak aby hashe kolidovaly???
V současné době je pouze popsáno to, jak vytvořit dva binární nesmysly se stejnou haší. Je to jednoduché a v řádu hodin.
V tento okamžik ale nelze s jistotou říci, že lze udělat body 1,2,3, protože tu metodu neznáme, nezveřejnili ji. Z bočních informací lze však usuzovat, že po jejím zveřejnění toto s určitou pravděpodobností možné bude. Pak by to také bylo jednoduché a v řádu hodin.
>Dál k internetovému bankovnictví:
Je možné, aby byl tedy po cestě mezi serverem a klientem změněn např. příkaz k úhradě, dopočítán md5sum a paket znovu šifrován veřejným klíčem banky a odeslán serveru???
Tohle je podobný problém jako s tím wordovským dokumentem, zkomplikovaný navíc šifrováním toho příkazu/dokumentu. Podstatné je, že tvůrcem příkazu je oprávněný uživatel a současně útočník. Může tedy poměrně dlouho bádat nad tím, jaký příkaz má vytvořit a současně aby byl schopen vytvořit smysluplný (stejně dlouhý) druhý příkaz se stejnou haší md5. V současné době funguje útok tak, že obě kolidující zprávy se liší jen v několika bitech. Pokud bude to spojení šifrováno proudovou šifrou (bývá tomu tak, RC4), stačí onu bitovou změnu provést na paketu se šifrovým textem (myslím, že nad tím už není kontrola integrity, ale kdyžtak mě opravte). Místo původního příkazu, zabezpečeného haší MD5 tak do banky putuje jiná zpráva (po odšifrování lišící se o pár bitů), se stejnou haší, tedy bude uznána jako autenticky odeslaná klientem. Proč by to ale klient dělal? Mohl takovou zprávu poslat rovnou. Takový útok by měl smysl, pokud by původní příkaz nebyl jeho, ale někoho jiného. Pak ale útočník nemá možnost kolidující zprávy vyrábět, musel by hledat kolidující zprávu ke zprávě jemu dané (vytvořené jiným klientem). To je jiná a v současné době neřešitelná úloha, jak bylo výše v diskusi už vyjasněno (hledání kolidující zprávy ke zprávě již dané).
>Jestli tomu rozumím, tak prolomení sha-1 by bylo možné dosáhnout také, jen na to zatím >nikdo nenašel vhodný algoritmus???
Prolomení hrubou silou možné je, ale nikoho nezajímá, protože je drahé a trvá příliš dlouho, rychlejší algoritmus nebyl nalezen a zatím nejsou signály, že by něco z publikovaných výsledků mělo přímý vliv na bezpečnost SHA-1.
>Je možné tedy v případě nalezení JEDNÉ kolize (třeba čistě náhodné), vytvořit právě >tento algoritmu fungující obecně???
Zatím rozhodně ne.
