Klávesové zkratky na tomto webu - základní­
Přeskočit hlavičku portálu


Diskuse k článku

„Šifra“ SHA-1 překonána: Google dokázal podvrhnout PDF se stejným hashem

Stále populární hashovací funkce SHA-1 byla považována za prakticky neprolomitelnou. Programátoři Google ve spolupráci s výzkumným centrem CWI Amsterdam názorně ukázali, že lze kontrolní šifrovací součet oklamat nejen teoreticky, ale i v praxi.

Upozornění

Litujeme, ale tato diskuse byla uzavřena a již do ní nelze vkládat nové příspěvky.
Děkujeme za pochopení.

Zobrazit příspěvky: Všechny podle vláken Všechny podle času

J81a60n 80D33l30o78u67h85ý 7874879100739

a za 10 let budeme to same cist o SHA-256. Kazde sifrovani/hashovani je prolomitelne. Je to jenom "otazka casu". Nicmene uz v roce 1995 jsem si pokladal otazku, ze preci musi jit udelat "jiny soubor", ktery po zahashovani stejny vysledek. Jen jaksi v te dobe by asi nikdo neplatil vyzkum nekolik let, jak to "udelat" ;-D

0/0
28.2.2017 11:18

M72i58l50a33n 19K39u31b13í28č43e79k 8462320634948

Václav Jůza:

Já to chápu tak, že je to nebezpečné jen relativně. Abys mohl vytvořit důvěryhodný soubor se stejným sha1 tak potřebuješ moře času, třeba jako oni při testech. A pokud využiješ těch informací, co oni zpracovali při tom dlouhým testu, tak to jde odhalit třeba tu:

https://shattered.io/

Napíše to tam "Collision found".

Takže pokud si myslíš, že je to nebezpečné, tak mi tu dej podvrhnutý soubor se stejným sha1, který nebude na tom webu detekovaný :-)

0/0
26.2.2017 5:56
Foto

P80a35v44e67l 23K33a14s57í57k16, 65T48e62c49h91n87e10t16.14c58z

Nebezpečné to je proto, že řada systémů může spoléhat na SHA-1 a ten systém to (zatím) oproti kolizi nekontroluje. Ale obecně vzato je to spíše připomínka toho, že počítače se zrychlují a to, co bylo před dvaceti lety nemyslitelné, je dnes proveditelné. A na to je v kryptografii potřeba myslet.

0/0
26.2.2017 15:10

M97i64l40a98n 77K42u52b77í28č65e10k 8962840214538

To ale přece zas není takový problém to do systému implementovat, třeba založený na tom kódu z githubu odkazovaný na shatteredu. A nejspíš to platí i pro jakýkoliv kolizní soubor vytvořený vlastními silamy. Vždy platí, že k souboru A nejde vytvořit kolizní soubor B, ale k tomu A se vytvoří Aa (s přidaným řetězcem, aby se dal vytvořit kolizní soubor Bb) a Bb, které mají stejné sha-1. A platí, že ty kolizní soubory pak jde detekovat, tedy Aa i Bb. Takže vlastně stačí při vytváření hashe zkontrolovat jestli neobsahuje vstupní soubor A "kolizní data" a pokud ano, tak jej třeba nepodepisovat, případně pokud někdo ověřuje soubor Aa a je kolizní tak jej brát jako nepodepsaný atd.

Jako já to myslel tak, že i po tom prolomení jde vlastně tu bezpečnost technicky zaručit a ověřit. Tím ale neříkám, že je to sha-1 bezpečné a molho by se používat.

0/0
26.2.2017 17:24

V61á83c39l51a67v 17J20ů87z82a 6271507316

Ano, asi dá se zjistit, že nějaký soubor je odvozený od této kolize nalezené googlem. Ale pokud někdo jiný (ať už nějaká tajná služba, či třeba zločinci) našli (ano, třeba po ročním počítání) nějakou jinou kolizi, kterou nezveřejnili, tak ji to pak neodhalí a mohou vesele využívat pro dokument s libovolným obsahem (ala ten generátor zmíněný níže).

Druhá věc je, že než imlementovat tuto kontrolu kolizí, tak je už jednodušší použít lepší hashovací funkci. Jediné, kde by asi mělo smysl tuto kontrolu implementovat, pokud systém hashe generující nelze změnit, tak tuto kontrolu udělat na straně oveřující.

+1/0
26.2.2017 22:03

M96i24l83a80n 81K91u63b26í47č82e65k 8482570334168

Tak jasně, že je bezpečnější přejít na lepší hashovací funkci. Teda tam, kde je to opravdu potřeba, se dávno (v hodně letech) na ni přešlo. Já to řešil pro takové případy, jako zvýšení/snížení platu o 10000 Kč, jak tu bylo uvedeno to pdf. A že ti určitě nemají prostředky na vytvoření třeba 9,223,372,036,854,775,808 SHA1. A že v takových případech stačí ještě ověřit kolizi, která existuje.

0/0
27.2.2017 0:39

P72a46v61e13l 64S32o96b33o79t88k27a 5300404

Jen technická poznámka k diskusi - MD5, SHA-1, a koneckonců ani CRC32 netřeba zatracovat.

Jen musíte vědět co a na co používáte.

Takže pokud si děláte kontrolní součty souborů, enerujete hash objektu či cokoli podobného, je MD5 aj. i nadále bez problémů.

Diskvalifikace se týká jen a pouze digitálního podepisování.

+3/0
25.2.2017 23:36

P57e42t43r 83F92i60a70l85a 3644485611246

To muselo dát práce..... A přitom taková blbost.

+1/−1
25.2.2017 0:38

P29a72v94e38l 76M66o15r16a14v55e64c 3852939692418

Blbost to není.

0/0
25.2.2017 17:47

J78a93n 52K33r48p57e79c 5336853214792

sice vubec nevim o cem se v clanku pojednava furt nejake cisla (asi gramaz v jakesi divne soustave), nejake prolomeni hashe, co ja vim tak hash jsme spise rozlamovali (a to uz pekne davno) nez prolamovali, asi nejaky novy techspeak, pac celou kostku by nevycadil ani kun...

0/0
24.2.2017 22:06

P83e19t70r 90N52o73v65e73k 6862642912266

Ne že poprvé byla překonána , ale poprvé bylo zveřejněno , že šifra byla překonána !!

+5/0
24.2.2017 13:54
Foto

P75a43v62e44l 46K86a10s63í88k49, 37T31e37c83h24n74e13t49.87c84z

Vzhledem k tomu, jak dlouho to trvalo a jak náročné to bylo, je docela možné, že to skutečně bylo poprvé.

+2/0
24.2.2017 17:34

P23a40v49e39l 67M10o92r76a92v96e26c 3592169462478

To nám ale NSA nikdy nepotvrdí.. :)

+1/0
25.2.2017 17:47

P93e89t82r 58S88v51o98b94o94d87a 7132841794

No vzhledem k poctu vypoctu ktere na to potrebovali a vzhledem k tomu ze pouze nasli 1 kolizi pro 2 podobne jednoduche PDF bych rekl ze neni duvod k panice.

Neco to samozrejme znamena. Znamena to ze je "prakticky" v urcitem konecnem case mozne nalezt kolizi pro SHA-1. Ale to "prakticky" pari zatim do uvozovek.

Teoreticky pri dostatecnem pocetnim vykonu lze najit kolizi k jakekoliv hash funkci a nebo prolomit jakoukoliv krypto funkci s vyjimkou Vermanovy sifry. (Teoreticky protoze Verman potrebuje zase generator nahodnych cisel a takovy dokonaly a pouzitelny random generator je take vicemene teorie)

+4/0
24.2.2017 13:16

K16a12r50e60l 76V46o75m61á50č69k92a 4131472398433

díky za info, pane Svodoba.

0/0
24.2.2017 13:35

F90r82a43n93t41i26š23e96k 88P89o72d95š20k55u68b32k65a 2581423107

Jaký to má vliv na kvašení okurek?

+2/0
24.2.2017 12:43

L56u31d63v19í45k 52G44a56j60d48o67š16í18k 2145623774742

Kdež je kvasíte v tem hešu, tož so pak hnusné.

+4/0
24.2.2017 17:08

J16i94ř89í 43K15o40c14u17r23e20k 6135184695468

Úplně stejný jako když bylo zavedeno nabodeníčko krátké a dlouhé.

+2/0
24.2.2017 19:51

P80e82t30r 96P47ř47i86k43r91y57l 1178885843

vůbec nechápu o čem je řeč. Takže bude se teda zdražovat nebo zevňovat ?

0/0
24.2.2017 12:29

M36a93r31t13i59n 78T88e60s27a37ř 2919433213593

Ukradnou vám z banky peníze, babi :-)

+1/0
24.2.2017 14:52
Foto

K10a75r16e63l 72M40a50l29ý 6676314700701

Sha256, MD5, rozdil. Popojedem.

0/0
24.2.2017 11:48

K67a27r20e62l 49V82o37m54á37č33k59a 4851792768133

můžete svou myšlenku trochu více rozvést? :)

0/0
24.2.2017 11:51

L69u32k29a30s 41S83u23c12h50a38n48e67k 5236657733630

Nejsem zrovna odborník na kryptování, ale tohle podvržení má smysl jen tehdy, pokud jsem schopen do "dokumentu" (nebo .exe souboru) podvrhnout vlastní funkční (čitelný) obsah, kterému by uživatel na základě ověření přes klič věřil, ačkoliv by v něm byly falešné údaje o bankovním účtu (v případě faktury) a nebo nějaký červík (v případě spustitelné aplikace).

Z článku jsem se nedozvěděl, zda se odborníkům z Googlu jen podařilo udělat "nějaký" dokument a nebo zda v něm mají to co chtějí oni a je to v podobě, která uživatele zmate.

+5/0
24.2.2017 11:19

K85a49r26e49l 76V89o82m63á19č60k73a 4301982128923

Připravit dokument se stejným otiskem, jako má jiný, už existující dokument, to už je panečku kolize úplně jiného řádu :)

0/0
24.2.2017 11:42
Foto

P49a21v29e86l 82K17a67s29í90k28, 58T96e95c75h28n50e14t21.83c81z

Protože jste si to nerozklikl :-) Jsou tam odkazy na ty soubory.

+1/0
24.2.2017 17:35

K95a96r22e92l 18V58o98m31á39č90k73a 4901302518653

pánové z google nás maliko za nos, poněvadž 9223372036854775808 je 2⁶³ přesně.

+1/0
24.2.2017 11:17

K59a54r45e81l 45V36o51m29á72č57k48a 4771522348783

aha, tak vodí nás technet - google říká "over ... operations" :)

0/0
24.2.2017 11:45

P77e32t85r 18S83o90k21o97l 8572901427761

Každá kryptografická matematická funkce je a bude překonatelná, kdykoliv od teď do budoucna. Je to jen otázka prostředků a času. Pokud na překonání jednoho kontrolního hashe potřebujete rok práce se 110 GPU, tak můžeme být v klidu, je to jako kdyby zloděj na překonání alarmu v domě potřeboval tři dny práce. V bezpečnosti existuje křivka, která říká, že za určitou mezí je zlepšení bezpečnosti neúměrně malé vůči neúnosně velkým nákladům. To je tenhle případ. Pokud je platnost hashe řádově sekunda a vy potřebujete hodinovou práci superpočítače abyste podvrhli jeden hash - např. při připojení na wifi nebo při výměně klíčů u vpn, tak je to stále solidní zabezpečení.

+6/0
24.2.2017 10:31

V97á49c61l98a51v 60J92ů82z23a 6621907206

Ale pokud je známa ta jedna kolize, vytvoření dalších z ní už je jednoduché (a my víme, že google jednu našel a zveřejnil, ale nevíme, kolik jich našli "zlí kluci" a nezveřejnil). A zneužilo by se to samozřejmě tam, kde je platnost hashe delší, než 1 sekunda - v tomto případě třeba elektronicky podepsané pdf dokumenty.

0/0
24.2.2017 10:39

P33e56t29r 68S68o39k79o75l 8442301177821

Poslední ověřitelné certifikáty s SHA-1 už nejsou rok platné, takže i podpis takovým certifikátem je už sám o sobě nedůvěryhodný. Kdyby bad boys měli úžasně velkou rainbow tabulku, není jim to nic platné. V praxi potřebujete vypočítat totožný hash pro konkrétní existující soubor, kterým chcete podvrhnout jiný a aby to bylo v praxi k něčemu musí být ten nový s konkrétním obsahem, čili musíte počítat abyste měl stejný hash i s potřebným obsahem. Podle toho co tu píšete, bych se domníval, že snad i věříte, že když změním jeden z těch odlišných 320byte bude mít soubor pořád stejný hash...nebude.

+1/0
24.2.2017 11:12
Foto

V78o32j92t73ě26c77h 46P42a82v37l98í68k 5784741354258

Spíš jde o to ukázat, že by se SHA-1 už mělo konečně přestat používat, stejně jako třeba starší MD5.

+2/0
24.2.2017 11:14

K60a23r54e31l 13V27o49m53á20č45k62a 4371832598963

je sice pravda, že je jedoduché teď připravit nekonečné množství dvojic SHA-1 kolizních souborů, avšak ty budou v podstatě zcela k ničemu.

0/0
24.2.2017 12:19

M75i55c87h81a73e23l 60P10r85i62n32c 7405585310135

To, co zveřejnili SHAttered ještě není důkaz, že SHA-1 je překonána. Ukázali, že je možné vygenerovat dva rozdílné pdf soubory se stejným hashem. Vypadá to, že udělat dva podobné pdf soubory trvá jeden rok, jenže neukázali, zda je možné napsat do pdf nebezpečný kód, který by něco skutečně provedl. Tedy, jestli je skutečně možné reálně modifikovat soubor k tomu, aby byl zneužit. Neukázali, jak vlastně ty dva pdf soubory vypadají.

Jestli bude někomu trvat 1 rok se 110 grafickými kartami, vygenerovat jeden podobný pdf soubor, jehož jedinou funkcí je shoda SHA-1 hashe, tak je SHA-1 stále dost bezpečná metoda.

Dále je třeba si uvědomit, že SHA-1 není často jediný zabezpečovací prvek, jak tu psal kolega níže. Jinak sami v článku píší, že SHA-1 se už na zabezpečení certifikačních autorit nepoužívá a ani používat nesmí. Tedy zabezpečení je stále napřed a není se třeba něčeho obávat, stačí být ve střehu.

+1/0
24.2.2017 10:00

V17á54c83l58a72v 27J79ů62z72a 6431687656

Je to nebezpečné. Ty dva soubory se liší jen v prvních 320 bajtech. Za tím může být cokoli, a pokud ten zbytek bude v obou souborech stejný, tak zase dostanete dokumenty se stejným hashem. Jak ty dva soubory vypadají ukázali, je na ně odkaz v článku. Liší se barvou záhlaví. Takže možná úplně jednoduchá zneužití (na která nebude potřeba počítat rok) jsou: např. jedné verzi červený text na modrém pozadí, v druhé verzi červený text na červeném pozadí. Dále myslím, že pdf umí i nějaké jednoduché skriptování, a možná by nějaký skript mohl mít kód podmíněný něčím v té části, co se liší.

Prostě z té jedné kolize už je mnohem jednodušší vyrobit kolize další, podle potřeby.

+1/0
24.2.2017 10:20

M89i66c79h70a85e94l 55P35r55i28n74c 7485625380825

Těch 320 bytů jste našel kde? Teprve po dlouhé době hledání jsem našel ty dva hypertextové odkazy. PDF1 a PDF 2. Stejně to nemění nic na zbývajících faktech, co jsem napsal. Jak moc ovlivnitelný je obsah, stále nevíme. Respektive malé části vyžadují enormní výpočetní výkon.

Reálně je možné na superpočítačích vytvořit každý jeden rok soubor se stejným hashem SHA-1, který nikdo na zabezpečení kritických součástí nepoužívá. V nebezpečí je pouze GIT.

0/0
24.2.2017 10:36

K95a10r98e19l 94V69o60m72á45č56k31a 4861622168893

ty bajty jsou přímo v tom souboru ;)

+2/0
24.2.2017 10:43

V97á25c92l51a74v 15J40ů36z76a 6221837816

Těch 320 bajtů zjistíte také, když si ty dokumenty PDF-1 a PDF-2 stáhnete a binárně porovnáte. Když to bude chtít někdo zneužít, nebude rok používat enormní výpočetní výkon, ale vymyslí, co za těch prvních 320 bajtů dá jiného, aby se mu to hodilo. Třeba se na to modré/červené pozadí napíše něco červeným písmem a dokument podepsaný SHA-1 se zašle dvěma smluvním stranám ke schválení.

0/0
24.2.2017 10:45
Foto

P50a78v71e86l 58K72a18s84í91k22, 70T33e19c68h78n27e64t95.95c39z

Tak to nefunguje. Hash se počítá z celého souboru.

+1/0
24.2.2017 20:35

V41á13c52l68a18v 35J61ů69z22a 6271577396

Ale funguje, jen jsem to možná nejasně napsal. Hash pracuje s proudem dat. A když je na pozici 320 ve stejném stavu v obou případech a další vstup se neliší, neliší se ani hash.

Neumím teď jednoduše vytvořit validní pozměněný PDF soubor, ale oni mají v tom pdf za pozicí 574 vložený JPEG obrázek, kdyby se tam vložil jiný obrázek stejných parametrů, bude to fungovat taky.

Ale na důkaz, že stačí to tak funguje (za pozicí 320 může být cookoli, ale musí to být v obou souborech stejné), můžete vyzkoušet toto:

$ sha1sum shattered-1.pdf

38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf

$ sha1sum shattered-2.pdf

38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf

$ dd if=shattered-1.pdf bs=1 count=320 of=base1

320+0 vstoupivších záznamů

320+0 vystoupivších záznamů

320 bajtů (320 B) zkopírováno, 0,00119548 s, 268 kB/s $ dd if=shattered-2.pdf bs=1 count=320 of=base2 320+0 vstoupivších záznamů 320+0 vystoupivších záznamů 320 bajtů (320 B) zkopírováno, 0,0012521 s, 256 kB/s $ echo "aaa" >otherfile $ cat base1 otherfile > new1.pdf $ cat base2 otherfile > new2.pdf $ sha1sum new1.pdf cb6e0199abd6850b95e6abe6dc34b18f22aac15c new1.pdf $ sha1sum new2.pdf cb6e0199abd6850b95e6abe6dc34b18f22aac15c new2.pdf

0/0
24.2.2017 22:47
Foto

P33a81v11e98l 37K71a38s74í91k82, 79T39e45c75h85n78e18t10.94c72z

To je přece úplné nepochopení, jak toho, co dělá SHA-1, tak toho, co udělali s tím shattered... V žádném případě neplatí, že by tam "za pozici 320" (jak tvrdíte) mohli dát cokoli a hash by se neměnil. Naopak, museli velmi dlouho počítat, co tam dát, aby výsledkem byl stejný hash. Ale dobře, přesvědčte mne, že máte pravdu, a vytvořte dva PDF soubory, jeden s textem "AAA" a jeden s textem "BBB", oba se stejným SHA-1 hashem. A pozor, neříkám, že je to nemožné (výzkumníci právě ukázali, že to možné je), ale říkám, že je to mnohem složitější, než říkáte. Hash se dělá z celého souboru, není žádná pozice, za kterou se už nehashuje.

+1/−1
25.2.2017 0:52

V68á24c72l25a27v 11J74ů41z24a 6771617196

Za pozicí 320 se hash mění, ale u obou variant stejně. Oni jednou dlouho počítali a pak vymysleli, jak tu kolizi použít pro libovolné dva obrázky stejného rozlišení.

Dva soubory (s komplikovanějším textem :-) ) a stejným SHA-1 hashem jsem pomocí generátoru vytvořil a odkaz dal v komentáři níže.

+2/0
25.2.2017 1:08

K20a70r94e47l 39V14o34m81á25č66k93a 4641262738603

už existuje služba, která nalezenou kolizi využívá - vyrobí dvě rozdílná PDFka se stejným SHA-1 hashem ze dvou uživatelsky uploadnutých obrázku. byl to docela příšek, nejde o PDF hacking, ale o JPEG hacking.

0/0
26.2.2017 23:19
Foto

V18o39j88t10ě97c53h 41P22a31v17l69í83k 5584191284638

Udělali to tak, že změnili obsah tak, jak potřebovali a do nevyužitého prostoru v soboru dali další data tak, aby výsledný hash vyšel, jak potřebovali.

Tedy současný útok umožňuje defakto libovolnou modifikaci, pokud v souboru je místo na nepoužitá data (v PDF je vždy, v JPG taky).

+4/0
24.2.2017 11:13

J30i86ř42í 98K40o50c14u62r50e15k 6395554945628

Tak jsem si to vyzkoušel. Vzal jsem soubor o velikosti 663865 B a udělal jeho kontrolní součet. Pak jsem na konec vložil prázdný řádek. SHA1 samozřejmě nesedí ani omylem.

$ sha1sum file

828a476a58575d52a1d0ad25578b966f1b09a903

$ echo "" >> file

$ sha1sum file

82ec7b30e95732ff0320fa31085644e35b08d402

0/0
24.2.2017 19:32

R64a85d38i10m 75Z86a82t64o39p12e50k 9862465372217

A proč by měly sedět, když konec řádku je taky znak (nebo 2 znaky)?

0/0
24.2.2017 19:55

J50i14ř93í 81K67o63c24u21r20e20k 6125104425158

Dva znaky: ^M ve Windows a \n v Unixu

0/0
25.2.2017 20:47

J44i88ř55í 83K30o41c81u11r93e79k 6265234425508

Vida, mají tu správně ošetřený input, nezmršilo se to :)

0/0
25.2.2017 20:48
Foto

P15a86v89e46l 20K80a81s51í25k43, 84T51e61c84h94n94e40t97.36c80z

Samozřejmě. To je přece smysl hashe.

+2/0
24.2.2017 20:36

V18á70c67l85a51v 56J94ů36z70a 6531767796

Měl jsem na mysli toto (otherfile může být cokoli):

$ sha1sum shattered-1.pdf

38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf

$ sha1sum shattered-2.pdf

38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf

$ dd if=shattered-1.pdf bs=1 count=320 of=base1

320+0 vstoupivších záznamů

320+0 vystoupivších záznamů

320 bajtů (320 B) zkopírováno, 0,00119548 s, 268 kB/s

$ dd if=shattered-2a.pdf bs=1 count=320 of=base2

320+0 vstoupivších záznamů 320+0 vystoupivších záznamů 320 bajtů (320 B) zkopírováno, 0,0012521 s, 256 kB/s $ echo "aaa" >otherfile $ cat base1 otherfile | sha1sum cb6e0199abd6850b95e6abe6dc34b18f22aac15c - $ cat base2 otherfile | sha1sum cb6e0199abd6850b95e6abe6dc34b18f22aac15c -

0/0
24.2.2017 21:54

V72á76c11l39a37v 60J83ů98z29a 6921367706

Omlouvám se za špátné zformátování v diskusi.

0/0
24.2.2017 22:01







Najdete na iDNES.cz



mobilní verze
© 1999–2017 MAFRA, a. s., a dodavatelé Profimedia, Reuters, ČTK, AP. Jakékoliv užití obsahu včetně převzetí, šíření či dalšího zpřístupňování článků a fotografií je bez souhlasu MAFRA, a. s., zakázáno. Provozovatelem serveru iDNES.cz je MAFRA, a. s., se sídlem
Karla Engliše 519/11, 150 00 Praha 5, IČ: 45313351, zapsaná v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 1328. Vydavatelství MAFRA, a. s., je členem koncernu AGROFERT.