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

J30a39n 38D74l29o34u85h83ý 7314269870339

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

M55i25l13a82n 69K66u58b91í71č67e56k 8872920584658

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

P61a39v69e58l 52K46a32s81í33k62, 45T36e18c58h27n97e78t63.27c69z

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

M22i37l20a91n 23K46u17b55í14č36e54k 8142610754938

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

V22á63c69l10a39v 96J59ů50z53a 6101177156

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

M54i49l84a33n 34K57u31b56í12č22e71k 8792880294618

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

P69a94v52e53l 23S71o51b71o92t51k18a 5220184

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

P46e43t97r 38F53i46a76l57a 3534855111146

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

+1/−1
25.2.2017 0:38

P53a69v48e71l 77M46o74r81a74v13e47c 3402379372268

Blbost to není.

0/0
25.2.2017 17:47

J34a87n 25K37r81p14e18c 5836603504772

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

P37e79t16r 53N33o61v53e24k 6692352742236

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

P48a65v16e18l 63K75a93s36í60k16, 70T93e82c50h47n69e75t26.53c23z

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

P83a61v18e91l 77M65o28r86a89v59e98c 3452289432918

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

+1/0
25.2.2017 17:47

P75e38t88r 48S58v84o37b38o71d72a 7972881574

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

K66a27r63e62l 63V79o39m97á27č46k41a 4471312798513

díky za info, pane Svodoba.

0/0
24.2.2017 13:35

F97r96a77n26t26i32š60e79k 26P27o17d94š49k68u42b63k88a 2271693127

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

+2/0
24.2.2017 12:43

L62u31d36v72í29k 54G44a19j21d34o84š93í14k 2965403544362

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

+4/0
24.2.2017 17:08

J65i51ř35í 85K74o65c65u84r63e23k 6755664665258

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

+2/0
24.2.2017 19:51

P29e23t84r 11P38ř64i24k36r98y61l 1588265933

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

M89a44r74t94i34n 33T52e64s41a75ř 2969653893813

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

+1/0
24.2.2017 14:52
Foto

K45a63r13e18l 32M45a67l29ý 6186494830641

Sha256, MD5, rozdil. Popojedem.

0/0
24.2.2017 11:48

K86a69r49e31l 22V11o72m36á11č70k36a 4241232178493

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

0/0
24.2.2017 11:51

L30u38k77a19s 16S14u40c70h71a66n85e60k 5596147183980

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

K21a90r25e10l 17V95o22m67á57č81k35a 4931752238803

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

P95a30v71e41l 28K46a22s68í50k79, 29T29e91c43h91n66e31t69.98c63z

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

+1/0
24.2.2017 17:35

K56a37r56e88l 26V30o78m96á24č88k39a 4631752548283

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

+1/0
24.2.2017 11:17

K13a77r77e24l 33V97o20m28á78č44k63a 4921302448223

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

0/0
24.2.2017 11:45

P84e24t55r 93S88o62k38o15l 8192571467571

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

V22á23c32l40a12v 71J63ů93z51a 6421397456

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

P87e12t18r 52S21o48k16o55l 8982141697601

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

V28o22j60t96ě68c64h 92P98a76v14l30í64k 5504391544448

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

K82a85r10e70l 90V25o90m27á98č43k62a 4751282118693

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

M19i14c78h28a62e64l 17P94r46i72n78c 7265745500215

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

V83á55c55l16a77v 93J82ů14z20a 6881677256

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

M24i81c64h31a17e61l 22P13r65i16n76c 7775265810255

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

K89a66r22e95l 38V61o90m47á25č13k49a 4831932688923

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

+2/0
24.2.2017 10:43

V93á72c17l57a38v 10J63ů67z68a 6371177346

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

P95a11v89e33l 97K26a81s79í47k13, 21T89e98c41h66n74e64t94.65c83z

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

+1/0
24.2.2017 20:35

V51á74c67l60a73v 76J97ů31z31a 6721277336

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

P30a13v61e47l 61K45a79s55í86k43, 95T92e81c83h59n22e28t82.29c64z

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

V25á27c35l64a44v 25J67ů13z60a 6971387726

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

K45a60r25e32l 43V45o53m91á77č41k62a 4471222308983

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

V38o95j51t43ě86c75h 33P51a45v53l48í29k 5774251254408

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

J68i18ř41í 57K65o25c55u61r29e54k 6565294645128

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

R12a30d98i71m 75Z34a28t44o89p59e25k 9602865362917

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

0/0
24.2.2017 19:55

J11i65ř25í 53K89o26c93u72r11e30k 6225794215748

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

0/0
25.2.2017 20:47

J78i44ř75í 84K30o96c86u98r33e68k 6955744665158

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

0/0
25.2.2017 20:48
Foto

P21a57v93e48l 31K42a83s63í95k13, 13T25e75c38h97n16e60t79.37c27z

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

+2/0
24.2.2017 20:36

V95á85c24l39a73v 55J80ů35z85a 6791777156

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

V95á95c85l11a96v 53J83ů45z18a 6721337276

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.