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

J61a31n 32D30l30o15u50h63ý 7974239750519

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

M95i89l34a60n 29K92u67b90í13č80e85k 8362940774128

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

P24a61v13e23l 95K90a30s69í87k26, 14T21e96c43h67n62e23t44.31c97z

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

M55i89l89a63n 59K71u97b80í44č94e34k 8522120594498

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

V46á20c62l54a15v 69J64ů71z12a 6871567936

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

M68i22l33a22n 60K55u14b43í33č70e49k 8622340914488

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

P34a91v91e61l 18S46o93b31o51t60k89a 5250384

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

P90e27t87r 75F13i76a39l68a 3214825731956

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

+1/−1
25.2.2017 0:38

P97a26v26e74l 69M98o29r23a30v39e79c 3202359482578

Blbost to není.

0/0
25.2.2017 17:47

J73a89n 80K60r69p40e74c 5526153824732

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

P59e56t62r 79N23o18v27e64k 6192302772556

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

P81a61v69e12l 17K60a47s76í49k64, 29T64e77c39h31n14e65t32.72c21z

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

P91a95v48e72l 59M50o25r70a91v70e38c 3362959442988

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

+1/0
25.2.2017 17:47

P98e98t38r 67S90v66o15b33o94d36a 7962111834

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

K86a23r97e85l 56V66o63m84á22č96k51a 4651452758843

díky za info, pane Svodoba.

0/0
24.2.2017 13:35

F77r35a92n68t42i40š31e14k 37P64o81d53š85k71u52b45k62a 2491413837

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

+2/0
24.2.2017 12:43

L77u71d51v78í38k 80G24a85j12d86o12š55í90k 2305553694432

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

+4/0
24.2.2017 17:08

J38i67ř52í 64K19o70c31u74r22e76k 6225694605888

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

+2/0
24.2.2017 19:51

P26e13t91r 16P16ř82i23k39r61y25l 1458115503

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

M62a35r62t65i26n 82T12e33s80a87ř 2289683103303

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

+1/0
24.2.2017 14:52
Foto

K14a25r13e11l 26M51a96l84ý 6526984230481

Sha256, MD5, rozdil. Popojedem.

0/0
24.2.2017 11:48

K85a30r97e15l 37V29o18m30á68č48k59a 4211952858583

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

0/0
24.2.2017 11:51

L64u44k24a72s 47S15u61c18h23a58n24e29k 5596527763820

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

K62a51r76e95l 80V34o74m60á98č60k79a 4611652658903

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

P15a39v91e42l 49K37a35s75í43k34, 21T84e55c22h98n57e77t90.64c95z

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

+1/0
24.2.2017 17:35

K69a28r89e76l 39V68o62m72á85č35k10a 4521572678183

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

+1/0
24.2.2017 11:17

K88a66r19e36l 54V37o75m43á71č68k49a 4291472108123

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

0/0
24.2.2017 11:45

P11e69t10r 68S31o85k49o24l 8132791747621

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

V88á17c33l68a36v 87J14ů20z90a 6681637206

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

P68e92t84r 27S18o88k49o24l 8722831337391

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

V52o88j46t31ě49c51h 15P55a79v73l85í35k 5474981224408

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

K43a88r21e42l 16V88o98m37á11č31k16a 4241402598893

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

M15i82c93h26a47e50l 81P70r48i62n17c 7395945170585

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

V78á18c75l18a80v 82J72ů90z33a 6621897196

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

M29i27c45h90a25e29l 83P79r52i53n82c 7745895610285

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

K71a79r97e58l 13V29o52m52á97č47k31a 4781162428913

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

+2/0
24.2.2017 10:43

V70á63c57l41a61v 52J13ů70z90a 6201217366

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

P16a35v34e11l 28K29a63s10í21k34, 13T85e88c76h73n46e53t93.50c76z

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

+1/0
24.2.2017 20:35

V47á59c82l28a27v 57J98ů74z67a 6181167486

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

P91a91v46e27l 72K46a12s59í51k41, 80T45e60c70h52n84e78t65.27c96z

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á43c88l55a51v 16J82ů70z29a 6881417126

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

K27a63r93e95l 39V56o73m16á90č90k34a 4151782468673

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

V56o15j24t95ě12c89h 19P79a57v13l89í74k 5664621414398

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

J62i98ř77í 27K96o75c55u54r31e90k 6215154765198

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

R82a75d15i47m 36Z64a15t91o39p22e18k 9822465912487

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

0/0
24.2.2017 19:55

J81i17ř52í 59K60o71c15u11r28e69k 6795584685748

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

0/0
25.2.2017 20:47

J20i78ř13í 12K48o29c24u68r28e36k 6755344695698

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

0/0
25.2.2017 20:48
Foto

P64a19v23e39l 62K15a49s83í67k55, 25T46e77c74h86n76e55t15.45c27z

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

+2/0
24.2.2017 20:36

V29á43c15l79a96v 72J34ů22z88a 6261827366

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

V11á45c46l19a56v 49J95ů63z34a 6351207576

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.