Vlákno názorů k článku Tunely v hašovacích funkcích: kolize MD5 do minuty od Danny_S - S bankou mam uzavrenou smlouvu o elektronickem bankovnictvi....
-
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.
