Názory k článku Tunely v hašovacích funkcích: kolize MD5 do minuty
-
Jakube, nic ve zlém, ale perex, tj. to, co je pod nadpisem, jsem nenapsal já, nýbrž redakce rootu na uvedení článku...
Takže česým kryptoanalytikem jsem se nenazval sám, to bych neudělal, ani kdyby to bylo bez překlepu.
Překlep bychom mohli redakci odpustit. Já tam mám taky překlep, který tímto opravuji:
Pod obrázkem 9:
"Na všech bitech i (i = 22, 23, 24) můžeme změnit hodnotu Q[9]i, aniž by to proměnné Q[11] a Q[10] zaregistrovaly."
Má tam být
"Na všech bitech i (i = 22, 23, 24) můžeme změnit hodnotu Q[9]i, aniž by to ROVNICE pro Q[.12.] a Q[.11.] zaregistrovaly."
Ještě tedy dovysvětlení. To je podstata tunelu. V tom systému těžce provázaných rovnic pro Q[1..64] a x[0..15] moci změnit něco (ve zprávě x[]), co nemá vliv na splnění cca 300 postačujících podmínek na proměnné Q[1..24], kde je každé slovo x[] použito a některé dvakrát. Vypadá to, že měníme Q[9], podstatou je, že měníme x[], aniž bychom se těch 300 podmínek dotkli. -
Clock (neregistrovaný)Rekneme ze zprava kterou nesmis rict se vejde do 128 znaku. Muzes
prosim rict vsechny 128-znakove zpravy ktere smis rict?
My si uz vylucovaci metodou vydedukujeme tu zpravu, kterou nesmis
rict.
Chapu ze prostor vsech zprav o delce 128 znaku je celkem velky,
ale to se da snadnou obejit RLE kompresi. -
Na Crypto-Worldu Vlastimil Klíma napsal:
Je potřeba vyvinout zcela nový koncept hašovacích funkcí, na čemž také usilovně pracuji, a z čehož je vlastně tahle práce vedlejší výsledek.
-
Martin Sedláček (neregistrovaný)Ta odpověď se mi moc líbí :-D Trošku mne ale popíchla k napsání následujícího, abych posunul Váš, jak jste sám řekl laický, pohled kupředu ;-)
Sw patenty jsou prostředek, kterým Vás může (ekonomicky) silnější soupeř cíleně zlikvidovat, kdykoliv mu začnete "lozit do zelí" (něco, co jste naprogramoval v rámci toho "blbě a málo" se náhodou třeba stane strašně blíbené/potřebné/užitečné/zábavné nebo cokoliv jiného a gigantu najednou začnou utíkat zisky za nějakou srajdičku, která Vašemu programu nesahá ani po kolena). Tak na Vás ukáže prstem a konec. Představa, že se budete moct nějak bránit je stejně úsměvná jako nereálná. Proto by sw patenty neměly existovat vůbec. Kdyby ti dnešní zastánci patentů měli platit všem předchozím generacím vědců. kteří zasvětili své životy, obětovali pohodlí atd., posunutí lidského vědění (které samozřejmě kdykoliv bezostyšně využívají) dopředu, ani by si za tou klávesnicí neprdli. Skuteční velikání (kupříkladu Donald Knuth) mají na patenty úplně jiný názor.
Martin -
Chápu, ale nejsem typický psavec SW. Píšu SW za trest, a ti, kdo ho musí číst, to mají buď za dobrodružství nebo taky za trest.
Kdybych měl tu možnost si něco nechat patentovat v EU, tak bych se na to vykašlal, protože na to nemám čas. Na to můžou mít čas velký firmy.
A jsme v tom samým kruhu jak tady už někdo psal, že SW patenty slouží velkým firmám. Právě proto, že psaní SW pro ně není náhodná, ale systematická činnost. Nedivím se tomu, že by si to chtěly uchránit. Ale podle mne jsou SW patenty a patenty na algoritmy brzda pokroku. Asi před deseti lety jsem v jednom rozhovoru dokonce poznamenal, že ..budu vypadat jako blázen, ale myslím si, že SW by měl být zadarmo...
Říkám jen co si myslím, ale jsem v tomhle oboru laik. -
anonymníOno se softwarovymi patenty je to slozitejsi nez program zadarmo nebo za penize.
Patenty chrani software jen velmi zprostredkovane. Jsou vydavany na algoritmy a ne na programy. A zrovna kryptografie je jedna z mala oblasti, kde je otazka zda by nejaka ochrana nemela byt. Je to obor kde se srazi nutnost algoritmy zverejnit k verejne validaci a soucasne potreba nejak zaplatit jejich autora.
Ja jsem zasadne proti patentum, jsou neskutecne zneuzivany. Ale zrovna ve Vasem pripade bych az tak proti nebyl. Investujete slusny kus zivota do vyvoje algoritmu, ktery bude celosvetove velmi uzitecny, pokud se povede, a spolecnost by mela uvazovat jakym zpusobem Vas odmenit. A odmena odvijejici se od poctu pouziti algoritmu ma hlubokou logiku, motivuje k tomu, aby algoritmus byl tak genialni, ze jej bude chtit pouzivat kazdy.
Ono je prima, ze budeme hashovat Klimou-I, ale BMW si za to nekoupite, kdezto takovy Pitr co mel parkrat stesti pri prelevani penez z uctu na ucet si ho kupuje kazdy rok nove.
Nebo znate nejakou metodu, jak kapitalizovat genialni objev ve sve oblasti? -
Robajz (neregistrovaný)Myslím, že by se to dalo kapitalizovat rozumě...
Nastavit platnost patentu na řekněme 1%-10% předpokládané doby "užitečnosti" objevu, nebo jiným způsobem, zkrátka rapidně ji zkrátit.
Takže bychom měli zbrusu novou hash funkci, půl / čtvrt roku by museli lidé za její použití platit a pak by byla nenávratně svobodná :)
Stejně si myslím, že je jednodušší (efektivnější) to rovnou vypustit a živit se buď díky sponzoringu, nebo implementací svého sw... -
1. ne, ale pracuje se na tom
2. ano, je to jen o málo složitější (podrobnosti jsou zrovna v článku ve Sdělovací technice č. 4). Něco vyjímám:
Dvě hašovací funkce
K nalezení kolize funkce MD5 || SHA1 potřebujeme pouze 2^80 zpráv, které mají stejnou MD5 haš. Mezi nimi nalezeneme pak dvě, které mají i stejnou SHA1, čili kolizi celé MD5 || SHA1. Trikem Jouxové získáme těch 2^80 zpráv pouze se složitostí POUZE 80 krát složitost nalezení jedné kolize MD5 (teď jednu kolizi umím na notebooku, na kterém píšu, jsem připojen na internet a běží mi test kolizí, za 30 sekund - trochu jsem původní program vylepšil). Získání těch 80 na sebe navazujících zpráv je teda za 2400 sekund. Zbývá je zkombinovat do 2^80 zpráv a zhašovat pomocí SHA-1. Čili je to až na tu hodinu práce navíc úplně stejné jako kdybychom vzali 2^80 libovolných zpráv a hledali v nich kolizi SHA-1. Poznamenávám, že tento dotaz jsem dostal i od pracovníka jedné velké certifikační autority.
Jedna hašovací funkce s více inicializačními hodnotami
Podobný dotaz, tentokrát od Panda Software, jsem dostal na možnost posílení haše pomocí dvou inicializačních vektorů. Nápad byl jako haš volit h(IV1, x) || h(IV2, x). Avšak použijeme-li trik Jouxové, dostáváme složitost útoku řádově jen 64 krát vyšší než pro samotné h(IV1, x). Avšak složitost se dále zvýší, pokud použijeme h(IV1, x) || h(IV2, x) || h(IV3, x). To jsem jim také doporučil (jako řešení jdoucí jejich směrem nikoli jako obecné, vůbec ne jako obecné). Uvažujeme-li konkrétně MD5 a že jsme schopni nalézt kolizi MD5 za jednu sekundu (na velkém stroji můžeme uvažovat za sekundu), pak kolizi MD5(IV1, x) || MD5(IV2, x) umíme trikem Jouxové najít se složitostí 64* 2^64 * 1s a kolizi MD5(IV1, x) || MD5(IV2, x) || MD5(IV3, x) se složitostí 64* (64* 2^64 * 1s), což je více než 2^64 hodin nebo přesněji je to 4096*2^64 krát složitější než jednoduchá kolize MD5. Čili tudy určitá cesta také vede (pro uzabřené systémy, kde je implementovaná MD5 a už není místo na kód, ale je tam místo i čas na výpočet trojnásobné haše s různými IV).
Další opatření.
Opatření šité na míru proti současným útokům, ale určitě účinné i na mnohé jiné útoky. Konkrétně můžeme z jednoho (například u MD5 a SHA1) 512-bitového bloku m, který máme zpracovat, vytvořit a zpracovat bloky dva, a to například m || C(m), kde C bude nějaký kontrolní kód bloku m. Pokud nám rychlost zařízení toto umožní, volíme C co nejsložitější (nedoporučuje se C(m) = m), ale například C jako nelineární zobrazení, dále zařazení čítače bloků do C(m) apod. Velmi mnoho opatření tohoto typu bylo navrženo na třech speciálních kryptologických konferencích, které řešily problémy hašovacích funkcí [6] [7] [8]. Pokud hledátě řešení tímto směrem, dobré jsou z těchto konferencí náměty z prací autorů Halevi - Krawczyk, Biham, Szydlo - Yin, Jutla - Patthak, Lucks, Rivest a Coron.
[6] Cryptographic Hash Workshop, NIST, USA, Oct. 31 - Nov. 1, 2005, http://www.csrc.nist.gov/pki/HashWorkshop/program.htm
[7] Conference on Hash Functions (Ecrypt), June 23-24, 2005, Przegorzaly (Krakow), Poland, http://www.ecrypt.eu.org/stvl/hfw/
[8] WEWoRC 2005, Western European Workshop on Research in Cryptology, Leuven-Heverlee, Belgium, July 5-7, 2005, http://www.cosic.esat.kuleuven.be/WeWorc/allAbstracts.pdf -
Yokotashi (neregistrovaný)V clanku byly zmineny slabe nelinearni fce, ktere nedostacuji ... jiz pojmenovani "slabe nelinearni" naznacuje, ze by mela existovat i trida silne nelinearnich. Je to uplna hovadina (proc jsem nesel na mffuk)?
Nebo se to nepouziva proto, ze se s tim prilis blbe pocita?
Pokud takove funkce existuji a nekdo o nich vite, hodte sem nejaky example pls. -
Právě v době psaní odpovědí na root mi dobíhá testík s upraveným SW. U původního programu jsem se vykašlal na druhý blok (cca 25 vteřin). Teď jsem doplnil dva tunely i do něj a je to za vteřinu. První blok má stabilní průměr 30 vteřin, takže celkem jedna kolize za 31 vteřin. Někdy naběhnou taky za vteřinu obě dvě. Slíbil jsem před rokem, že program zveřejním, až to stokrát urychlím, teď je to tisíckrát, tak tím s MD5 už končím, i když je tam ještě práce jak na kostele. Například navrhnout diferenční schéma, které by a priori obsahovalo pořádný tunel nebo k dané právě najít jinou se stejnou haší....
-
2ge (neregistrovaný)Zdravicko p.Klima,
klubok dole pred takymto clankom a za vsetko co ste do kryptografie priniesli. Predpokladam, ze ked zverejnite Vas program, MD5 sa stane dalsou nepodporovanou hashovacou fciou pre jej slabiny. Ak to pojde takto s Vami dalej, tak zachvilu nebudeme mat ziadne pouzitelne hashovacie metody :) -
Nebojte, pracuje se na tom.
Už je to přes rok, měl jsem přednášku, kterou jsem nazval "Nedůvěřujte kryptologům". Myslel jsem to vážně (to víte, ty názvy přednášek na konference... najdete jí někde na mém webu, měla by tam být), rozvíjím tam myšlenku, že je normální, že kryptografické techniky stárnou a je potřeba je obnovovat, jako cokoli v našem životě. Dříve to nebylo zvykem, protože se o tom nepsalo, nevědělo, nebádalo se veřejně. Nové je pouze to, že teď si to uvědomujeme a musíme si na to zvyknout.
Jinak díky za hezká slova na mojí adresu.
Abych z toho udělal trochu srandu. Jak tady říkal někdo v diskusi, spíš bude mít dojem, že jsem něco odnesl... -
Tak jsem to tam dal, viz domácí stránka projektu http://cryptography.hyperlink.cz/2004/kolize_hash.htm.
-
Pavel TišnovskýZlatý podporovatelTen zdroják náhodou vypadá docela dobře, ještě že jste neviděl zdrojový kód od jedné matematičky, která pro nás externě vytvářela podpůrné aplikace :-)
Asi začnu pro označování lokálních znakových proměnných taky používat název 'bukva', nějak se mi to zalíbilo :-) -
Pavel TišnovskýZlatý podporovatelNojo, ale ze jmena promenne "hlavne_ze_je_vecirek" asi nezjistim jeji vyznam (mozna, na zdrojaky linkse se mrknu, clovek se rad priuci :-). Ta "bukva" ma neco do sebe, je to zabavnejsi nez me obligatni "c" nebo "ch". Ten zdrojak od pani matematicky je plny promenych typu kmh01s, kmh02s, kmk3bk atd. (celkem toho je tak na pet A4) a vsechno je to pro jistotu nadeklarovane globalne (aby se nemusely pouzivat structy, parametry funkci a returny :-)
-
Dejte tam SHA-256 nebo SHA-512 at mate chvili klid.
Stahovani SHA-1 vyhlasil uz i americky NIST.
Letos se ocekava zverejneni kolize.
Viz například
Kolizi SHA-1 lze dnes nalézt se 160 tisíci $ za 127 dní nebo s 10 miliony $ za 2 dny
na http://crypto-world.info/news/index.php?prispevek=2249
nebo
Stanovisko NIST k dalšímu používání hashovacích funkcí
na
http://crypto-world.info/news/index.php?prispevek=2946 -
Danny_S (neregistrovaný)Pouzívám sifrovací software pro práci s sifrovanými disky - kontejnery a SHA 256 a 512 nenabízí. Kromě SHA-1 nabízí pro vytvoření hashe buď RIPEMD 160 nebo Whirrpool.
Jak jsou na tom tyto hashovací algorytmy? Jsou stejně spatne jako MD5 nebo SHA1, nebo jsou schponou alterantivou k SHA 2565 a 512. Je mozne jich vyuzivat jeste pul roku rok, nezvynaleznete novou koncepci hashovani? To berte prosim jako poklonu a pochavlu.
Diky -
To používáte TrueCrypt (http://www.truecrypt.org/), že? Pěkný kousek software, také ho používám. A rozhodně by mě také zajímala odpověď na Vámi položenou otázku. -
mato (neregistrovaný)odporucil by som pozriet sa na geom(8) vo freebsd... :-)
http://www.freebsd.org/cgi/man.cgi?query=geli&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html -
Danny_S (neregistrovaný)S bankou mam uzavrenou smlouvu o elektronickem bankovnictvi. Je pouzito asymetrického sifrovani s verejnym klicem. Verejny klic je registrovan (a umisten) na bankovnim serveru.
Ve smlouve je tento klic uveden - je vytistena jeho textova verze i je zde uveden i jeho MD5 otisk.
Kazdou transakci musim podepsat svym soukromym klicem, ktery znam jen ja a ke kteremu zadna MD5 neni nikde zverejnena.
Predpokladam, ze zrychleny vypocet kolize v MD5 se na bezpečnosti moji komunikace s bankou - ktera uvedla MD5 otisk VEREHJNEHO klice do smlouvy o bankonictvi - zatim neprojevi a nema zadny vliv.
Neb:
* MD5 ve smlouvě je generovaná z veřejného a ne soukromého klíče.
* Nepodepisuji otiskem MD5, ale celym soukromým klíčem s heslem který nikdo nemá.
Ale mozná se pletu. Nerozumím výslednému procesu podepsání úplně.Co se fyzicky děje s mailem, který je třeba podespán soukromým klíčem, nebo bankovním příkazem? Jak zjistí příjemce mailu, nebo bankovního příkazu vlastnící můj veřejný klíč, že jsem to podespal já - svým soukromým klíčem?
Neprobíhá v tom procesu ověřování pravosti mého podpisu také nějaké genování MD5 nebo SHA-1, které by celý proces zpochybňovalo?
Můžete mi to proím někdo vysvětil?
Každopádně pokud by to i tak nějak bylo, musel by stejně útočník znát MD5 otisk mého soukromého klíče a k němu se pokusit vygenrovat kolizní soubor - falesný soukromý klíč se stejnou MD5tkou ne?
Tzn. muselo by nejdřív dojít k odcizení soukromého klíče, nebo alespoň k zjištění jeho MD hashe, aby se útočník mohl falesne podepisvat místo mě, ne?
Kdyžtak mě prosím opravte, nebo to vysvětzlete. Dík. -
Urcite vam to tady nekdo vysvetli, ja jen odpovim na cast dotazu, na to, ze zrychleny vypocet kolize MD5 nema na vasi situaci s bankou jak to tak zvonkajsku vypada ZADNY PRIMY vliv.
Tak to vypada na prvni pohled. Rozhodne nechci strasit, verte mi. Jen je nutno vedet, ze ruzne SW, ktere banka pouziva, a kudy ty transakce vsechny prochazeji, temer urcite nekde pouzivaji jeste MD5, protoze ty softy jsou slepene z ruznych slepencu, starych i novych. Mohu vam rici ze zkusenosti, ze zadny clovek v bance X nevi, jaky SW se na ruznych mistech banky a v ruznych systemech pouziva a co vsechno v nem je. Potkal jsem velmi chytre programatory, velmi chytre bezpecaky a velmi vychytrale manazery (u nich je to vychytrale vlastne synonymum pro chytre, to vyplyva z pracovni naplne). I ty ostatni. Programatori prichazeji a odchazeji, systemy se meni a ridici pracovnici nevi jestli v nejakem softu je MD5 nebo SHA-1, kdyz sami ani nevi, co to je. Takze odpoved na vasi otazku je slozita.
Nijak nespecifikuji banku X. Chytri se dovtipi. -
No, pozadej vsechny, s kym budes chtit obchodovat, aby si ten verejny klic stahli driv nez si prectou tenhle clanek. Az si ho prectou, muzes mavat smlouvou jak chces, stejne ti nebudou verit ze je to tvuj klic, pokud to nebudou moci overit jinak nez podle otisku na smlouve (namatkou ho muzou overit podle toho, ze ho maji zkopirovany dele nez se umi delat kolize md5, nebo podle toho, ze je soucasti podepsaneho certifikatu - teda pokud ten certifikat nepouziva md5). Ty kryptograficky zdatnejsi mozna presvedcis, ze staci kdyz je ta smlouva starsi nez to generovani kolizi, ale tezko rict jak dlouho kdyz Klima rika, ze se pracuje i na kolizi prvniho radu ...
Pokud komunikace probiha pouze s bankou, melo by to byt bezpecne (zarucit to bez analyzy veskereho zucastneneho kodu nejde), protoze banka ten verejny klic ma delsi dobu a nepochybne u nej ma poznamenano, ze je vas (a snad ne pomoci md5). -
hstech (neregistrovaný)> Co se fyzicky děje s mailem, který je třeba podespán soukromým klíčem?
Vygeneruje sa hash danej správy (v súčasnosti asi MD5 nebo SHA1), tento hash
sa zašifruje tvojím súkromným kľúčom a priloží k správe.
> Jak zjistí příjemce mailu, nebo bankovního příkazu vlastnící můj veřejný
> klíč, že jsem to podespal já - svým soukromým klíčem?
Vygeneruje si hash správy, potom dešifruje priložený podpis tvojím verejným
kľúčom a porovná. Verejným kľúčom sa dajú dešifrovať iba dáta zašifrované
príslušným súkromným kľúčom.
> Neprobíhá v tom procesu ověřování pravosti mého podpisu také nějaké
> genování MD5 nebo SHA-1, které by celý proces zpochybňovalo?
To je práve ten problém, že prebieha. Ak je protokol dostatočne nemožný
(napr. podpisovať .EXE súbor, ktorý po spustení "vypľuje" danú správu
alebo podpisovať Microsoft Word dokument), stáva sa podpis bezcenným pri
použití slabej hash funkcie. Preto sa solídne kryptografické aplikácie
musia navrhovať tak, aby použité kryptografické prostriedky bolo možné bez
väčších problémov vymeniť.
> Každopádně pokud by to i tak nějak bylo, musel by stejně útočník znát
> MD5 otisk mého soukromého klíče a k němu se pokusit vygenrovat kolizní
> soubor - falesný soukromý klíč se stejnou MD5tkou ne?
MD5 otisk súkromného kľúča mu bude nanič. Falošný súkromný kľúč s rovnakým MD5 mu takisto bude nanič (nepôjdú s ním rozšifrovať správy zašifrované pravým verejným kľúčom). To, čo útočník potrebuje je falošný VEREJNÝ kľúč s rovnakým MD5. Potom sa môže "napichnúť" niekde medzi odosielateľom a príjimateľom, správy od odosielateľa rozšifruje svojím súkromným kľúčom, ktorý patrí k onomu falošnému verejnému kľúču, zašifruje pravým verejným kľúčom a pošle ďalej. Takto môže odpočúvať komunikáciu. Vraví sa tomu "man in the middle attack".
> Tzn. muselo by nejdřív dojít k odcizení soukromého klíče, nebo alespoň k
> zjištění jeho MD hashe, aby se útočník mohl falesne podepisvat místo mě,
> ne?
Aby sa mohol falošne podpisovať miesto teba, potrebuje tvoj súkromný kľúč.
Hash sa na podpisovanie nedá použit a takisto nestačí ak bude mať iba
nejaký súkromný kľúč, ktorý je odlišný od tvojho (i napriek tomu, že bude
mať rovnaké MD5 ako ten tvoj kľúč). Ide o to, že pri tých procesoch sa
používa daný kľúč taký, aký je, nie iba nejaká jeho hash. -
hstech (neregistrovaný)Mozno je čas na zmenu spôsobu podpisovania správ. Napríklad takto:
Podpisovaná správa sa skomprimuje nejakým silne kompresným algoritmom typu bzip2 alebo podobným. Tento kompresný algoritmus nesmie generovať žiadne "jalové dáta", ktoré na dekomprimovanú podobu dokumentu nemajú žiadny vplyv. Skomprimovaná správa sa potom rozseká na niekoľko rôzne veľkých blokov, pričom treba dať pozor na to, aby tieto rozseknutia neboli presne na miestach, kde použitý kompresný algoritmus rozsekol výstupný dátový prúd (napríklad bzip2 algoritmus generuje "rozsekaný" výstup). Pre každý z týchto blokov sa vygeneruje hash. Tieto hashe sa spolu s príslušnými dĺžkami blokov, informáciami o použitom kompresnom algoritme a dĺžkou neskomprimovanej podoby dokumentu zašifrujú príslušným súkromným kľúčom a priložia k skomprimovanej správe.
Kontrola sa vykoná tak, že sa dešifruje podpis, vypočítajú hashe blokov a porovnajú s uloženými, ak niektorý nesedí, chyba. Potom sa program s použitím uložených informácií o použitom kompresnom algoritme pokúsi dokument dekomprimovať. Ak sa mu to nepodarí alebo síce dokument úspešne dekomprimuje ale ostanú nejaké nespotrebované dáta, opäť chyba.
Silu zabezpečenia je možné meniť zmenou počtu fragmentov na ktoré sa skomprimovaný dokument rozseká (čím viac, tým lepšie).
Myslím, že tento formát podpísaných dokumentov by nebolo také jednoduché prelomiť ako štandardný "spočítať hash a priložiť". Útočník by totiž musel nájsť kolidujúci blok, ktorý má nielen rovnakú hash ale aj rovnakú dĺžku ako príslušný pôvodný blok a navyše musí byť platným fragmentom výstupu použitého kompresného algoritmu, ktorý "zapadne" na príslušné miesto. A navyše nový fragment musí vygenerovať presne toľko bajtov ako pôvodný (inak nebude sedieť dĺžka dekomprimovaného dokumentu uložená v podpise).
Chcel by som vidieť maniaka, ktorému sa podarí toto prelomiť.
Je síce pravda, že podpisovanie a overovanie v tomto formáte je pomalé ale pokiaľ ide o dokumenty, ktoré predstavujú napríklad niekoľkomiliónové kontrakty, tých pár CPU cyklov navyše mi za tú zvýšenú dôveryhodnosť podpisu rozhodne stojí. -
Problém je v tom, že tvůrci nebo oprašovači informačních systémů nejsou ochotni změnit vůbec nic, pokud to přímo neohrožuje jejich byznys a byznys jejich zaměstnavatelů. Navrhovaná úprava by pro tyhle lidi byla nepřijatelná. Ony jsou už navrženy jiné hašovací funkce i nové varianty norem pro digitální podpis, ale nikdo je nechce nasazovat. Přesto, že ty staré mají chyby, které jsou popsané, uznané a mnohdy nebezpečné. Nejdůležitější je kompatibilita - a každá změna ji trochu narušuje, i když (některé) systémy se změnou různých funkcí (jako je šifrovací algoritmus, hašovací,....) už nějakou dobu počítají. Třeba pro certifikační autoritu nebo pro Microsoft je záměna hašovací funkce jen otázkou změny identifikátoru. Ale co ty softy, které na to navazují ? Je sice hezké, že CA nebo MS změní identifikátor, ale ty návazné softy musí také ty nové funkce zapracovat, aby tomu identifikátoru rozuměly, atd. atd.... A všechno se točí jen kolem prachů. Bezpečnost? To nevydělává. Něco tam dejte, ať to hlavně moc nestojí a nějak to zařiďte....
-
hstech (neregistrovaný)> Problém je v tom, že tvůrci nebo oprašovači informačních
> systémů nejsou ochotni změnit vůbec nic, pokud to přímo
> neohrožuje jejich byznys a byznys jejich zaměstnavatelů.
Hm. Toto ma nenapadlo. Myslím si, že máte pravdu. Najmä čo sa všelijakého closed-source softwaru týka. Viem si celkom dobre predstavit, že ten software upraviť pre nové podmienky jednoducho nepôjde (sám vyvíjam software a tiež sa mi niečo podobné stalo - po určitom čase sa mi projekt "zasekol" a jediná možnosť ako v tom pokračovať bolo celý ho odznova prepísať).
> Navrhovaná úprava by pro tyhle lidi byla nepřijatelná.
> Ony jsou už navrženy jiné hašovací funkce i nové
> varianty norem pro digitální podpis, ale nikdo je nechce
> nasazovat. Přesto, že ty staré mají chyby, které jsou
> popsané, uznané a mnohdy nebezpečné.
Pokým na to nedoplatia. Keď vďaka tomuto prístupu dôjde k obrovským škodám, nasadzovanie bude pravdepodobne vynútené zákonom. Začínam si spomínať na to, že pravdepodobne ide o typický "americký syndróm". Podobne Amíci pristupujú aj k otázkam bezpečnosti (najprv musí zomrieť niekoľko ľudí, až potom sa s bezpečnosťou systému, ktorý je za to zodpovedný, začne niečo robiť).
> Ale co ty softy, které na to navazují ? Je sice hezké,
> že CA nebo MS změní identifikátor, ale ty návazné softy
> musí také ty nové funkce zapracovat, aby tomu
> identifikátoru rozuměly, atd. atd.... A všechno se točí
> jen kolem prachů. Bezpečnost? To nevydělává. Něco tam
> dejte, ať to hlavně moc nestojí a nějak to zařiďte....
Open source sa prispôsobí ľahko (ako to tu bolo už x-krát naznačené, u väčšiny open source projektov peniaze nehrajú až takú významnú rolu ako v prípade typických proprietárných produktov) a proprietary software nás príliš trápiť nemusí. Napokon to možno dopadne tak, že v tejto oblasti open source nechá svojích proprietárnych rivalov beznádejne vzadu :) M$ sa možno bude pokúšať niečo proti Open Source riešiť s pomocou patentov ale keď dané patentované algoritmy zastarajú skôr ako stihnú tohoto ich súpera významne poškodiť, nezostane im iné ako s vyplazeným jazykom doháňať.
Záver: Uvedené vysvetlenie považujem za viac ako dostatočné. -
hstech (neregistrovaný)Mám ešte jednu otázku. Nechajme bokom otázky o financiách a "ochote niečo meniť" a sústreďme sa na metódu ako takú. Nakoľko to bude odolné? Aká je šanca, že útočník môže úspešne zneužiť kryptograficku slabinu nejakej hash funkcie použitej pri podpisovaní, keď formát podpisu bude ako bolo už predtým naznačené?
-
Zájemce o toto téma bych chtěl upozornit na nové číslo Crypto-Worldu, které vyjde během dubna (k jeho odběru je potřeba se zaregistrovat). Bude tam velice zajímavý článek pana Klímy Kolize MD5 do minuty aneb co v odborných zprávách nenajdete popisující zákulisí této oblasti a i některé myšlenky do budoucna.
ČLÁNKY DO MAILU