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

J73a33n 57D31l27o42u23h11ý 7724289680809

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

M36i23l14a84n 84K35u86b86í65č37e26k 8972620884318

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

P89a73v78e60l 88K97a39s68í83k88, 65T98e70c36h72n29e19t20.50c48z

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

M50i62l88a59n 47K66u46b17í94č41e33k 8642530904208

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

V98á49c18l91a74v 95J53ů29z95a 6291367256

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

M59i92l17a16n 86K21u49b80í37č84e28k 8222310604328

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

P73a51v65e11l 55S78o26b72o79t11k28a 5740524

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

P95e42t92r 39F21i50a86l24a 3864355451526

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

+1/−1
25.2.2017 0:38

P13a20v81e23l 30M94o69r24a73v79e76c 3402289792468

Blbost to není.

0/0
25.2.2017 17:47

J42a29n 37K14r67p46e95c 5836933914882

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

P11e79t72r 17N85o26v29e57k 6512682432596

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

P59a15v58e60l 78K26a64s62í21k40, 14T53e93c59h30n77e16t17.36c87z

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

P31a41v92e89l 50M65o92r60a20v69e38c 3762989692778

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

+1/0
25.2.2017 17:47

P97e19t84r 27S67v38o39b76o70d74a 7292221364

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

O95d51s51t44r42a55n37ě27n21ý 68U20ž22i32v14a51t51e11l

Uživatel požádal o vymazání
0/0
24.2.2017 13:35

F37r54a34n81t31i68š31e88k 68P58o91d64š32k24u31b52k66a 2641683277

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

+2/0
24.2.2017 12:43

L93u44d53v42í59k 85G49a73j14d44o34š86í34k 2695473744872

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

+4/0
24.2.2017 17:08

J54i73ř81í 30K54o73c95u44r62e88k 6545884685648

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

+2/0
24.2.2017 19:51

P49e81t33r 16P91ř10i91k31r44y28l 1568845333

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

M14a39r61t75i55n 64T22e89s85a96ř 2499703563963

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

+1/0
24.2.2017 14:52
Foto

K96a96r94e83l 44M78a84l15ý 6106624550731

Sha256, MD5, rozdil. Popojedem.

0/0
24.2.2017 11:48

O95d32s38t63r72a68n49ě71n39ý 33U36ž77i42v14a52t58e94l

Uživatel požádal o vymazání
0/0
24.2.2017 11:51

L36u66k30a53s 93S34u47c32h71a49n53e49k 5986387983300

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

O81d68s88t61r32a33n79ě31n84ý 66U72ž69i27v51a40t36e35l

Uživatel požádal o vymazání
0/0
24.2.2017 11:42
Foto

P19a73v94e34l 30K11a97s89í41k11, 28T95e32c40h93n37e57t60.45c62z

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

+1/0
24.2.2017 17:35

O95d72s13t85r98a67n36ě60n77ý 15U30ž19i27v23a88t64e13l

Uživatel požádal o vymazání
+1/0
24.2.2017 11:17

O94d60s66t90r70a89n31ě60n34ý 62U36ž77i41v68a89t94e73l

Uživatel požádal o vymazání
0/0
24.2.2017 11:45

P39e45t69r 19S34o61k74o46l 8222361807191

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

V77á18c50l39a33v 62J98ů78z70a 6351827806

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

P34e73t15r 10S81o45k45o39l 8242531837531

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

V93o93j69t98ě90c53h 58P63a50v51l56í53k 5844481184168

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

O90d25s12t13r62a87n83ě60n56ý 73U64ž75i90v50a94t34e34l

Uživatel požádal o vymazání
0/0
24.2.2017 12:19

M96i45c39h91a10e86l 26P75r29i40n82c 7275605250435

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

V79á89c16l20a19v 51J27ů88z82a 6711107566

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

M31i28c86h13a77e24l 89P38r84i36n43c 7575105420955

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

O58d31s47t61r11a95n83ě54n16ý 38U29ž82i58v68a37t92e56l

Uživatel požádal o vymazání
+2/0
24.2.2017 10:43

V40á36c95l41a37v 40J59ů24z57a 6681647526

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

P56a58v19e75l 54K67a67s44í20k97, 59T46e73c79h73n58e41t41.68c57z

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

+1/0
24.2.2017 20:35

V42á86c27l73a46v 63J30ů90z87a 6471527376

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

P11a59v79e19l 16K13a10s69í57k45, 41T76e58c67h56n65e10t82.26c98z

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

V17á19c69l40a44v 39J90ů47z76a 6561727546

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

O32d28s71t30r92a48n34ě38n68ý 87U84ž50i84v95a86t94e73l

Uživatel požádal o vymazání
0/0
26.2.2017 23:19
Foto

V34o86j64t36ě37c21h 91P89a48v73l75í21k 5624921114728

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

J85i54ř40í 95K36o72c60u57r87e40k 6285344285558

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

R48a51d95i72m 52Z68a17t28o93p16e79k 9392535742577

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

0/0
24.2.2017 19:55

J26i15ř94í 82K76o97c51u56r98e46k 6605364165488

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

0/0
25.2.2017 20:47

J95i91ř66í 70K92o35c34u25r89e50k 6415644675598

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

0/0
25.2.2017 20:48
Foto

P33a26v95e29l 85K98a70s35í33k50, 50T56e95c93h95n36e90t42.11c78z

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

+2/0
24.2.2017 20:36

V96á24c22l67a59v 48J33ů11z25a 6541517226

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

V39á91c33l82a49v 41J50ů17z76a 6701677256

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

0/0
24.2.2017 22:01



Najdete na iDNES.cz