Remcalove tvrdej, ze cely sifrovani je khovnu, kdyz se dela tak, ze ty tzv "nebezepeny" sifry prestavaj fungovat, protoze tim se leda uzivatelum rika "nesifrujte, protoze to nefunguje".
Kvuli podobnym kokotum jako tem z chrozili udrzuju 5 verzi browseru a 5 verzi javy. K tomu brzi pribude flash (zajimavy, jak narozdil od javy i nejnovejsi flash vpohode zvladne desetileti starej obsah).
A sem vazne zvedav, kdy konecne nekdo vykopne moznost se prihlasit k "nezasifrovany" wifi ... pripadne znemozni pouzivat WEP. Sem vazne zvedav, jak vsichni rozslapnou ty svoje krabky a budou kazdyho 1/2 roku kupovat novy.
Pricezm tady jde o nebezpeci hypoteticko-teoreticky, kdezto s nefunkcnim systemem CA, kde se opakovane dlouhodobe ukazuje ze nebezpeci je zcela realny a kazdodenne pritomy, se nedela nic. Protoze i TB klic a 10 ruznych hashu je ti khovnu, kdyz stejnej klic ta tvoje uzasna CA vyda komukoli dalsimu.
Hledej na tom to pozitivní. Vyvine se tím tlak na firmy typu SPZ (Sbastlím - Prodám - Zapomenu), aby začali s nějakou údržbou firmware...
Tobě přijde normální, když si firma objedná za 100M mašinu, z daní ji odepisuje 10 let a po třech letech už se s ní nedá komunikovat, protože dodavatel na to hází bobek?
Jenze dodavatel resi, jestli ta masina masinuje a hazi bobek na to, ze konfiguracni nastroj, kterej se pouzije jednou za rok, a kterej vzivote nikdo nikdy z internetu nepouzije, nepodporuje nejfrikulinstejsi verze sifrovani.
Zato ten servisak pak resi, ze k tomu prijde se svym notesem, a nefunguje mu to, protoze se zrovna opatchoval jeho ubezbezpecnej browser. Coz je porad jeste ten mensi problem, protoze servisak si zanadava a poradi. Kdezo BFu kterymu doma prestaho fungovat ovladani televize ... to vyresi jednoduse, nainstaluje zpatky verzi se kterou to funguje, a zakaze aktualizace. A presne tu verzi bude pouzivat i pro browseni po webu.
Otázka zněla, zda ti přijde normální, že na mašinu za 100M po třech letech už výrobce hází bobek.
A to se vůbec nemusíme bavit o šifrování. Aktuálně řešíme případ se zařízením, jehož pořizovací cena byla přes milion a jehož předchůdce fungoval bez mála 30 let. A u tohoto zařízení je problém technického rázu s jednou součástkou. A dodavatel nám řekl, že to nebude dále řešit, že my si máme pořídit do zásoby tuto součástku a že on to bude jen vyměňovat (samozřejmě že mu to pokaždé zaplatíme).
Tenhle přístup, kdy dokonce odmítají mít i skladem náhradní díly na již prodané stroje je teda dost ... nešťastný.
U zařízení za tyto částky bych očekával jiný přístup. A zrovna opatchovat firmware je ta nejmenší práce. Nehledě na to, že u výrobku v cenové kategorii 100M bych možná očekával speciální terminál pro ovládání té mašiny a nikoliv obyčejný webový prohlížeč.
Masina za 100M se bude pouzivat 30let. Sem si skoro jistej, ze porad najdes v provozu "CNCcka" programovany dratovanim.
Pristup je danej smlouvou, pokud mas smlouvu na ktery dodavatel nic negarantuje, tak mas servis tomu presne odpovidajici = zadnej. Samo, muzes reagovat tak, ze od takovyho dodavatel uz nic nekoupis, coz ti je hovno platny, kdyz tu masinu mas, a vyhodit ji nechces.
Se podivej jakej uzasne servis se poskytuje v IT ... zaplatis dvojnasobek ceny ... a ... vymena disku trva mesic. Mezi tim chcipnou dalsi dva. Zaklatis "100% garantovanej geografickej cluster" ... a staci par kapek vody aby "cluster" nejen dlouhy dny nefungoval vubec, ale i prisel o data.
A ted do tyhle situace, kdy ani za miliony nedostanes support, dosad BFUcka s jejich kramama za par stokorun, maximalne tisicikorun. ...
btw ... sem tak nejak kolem zaslech, ze ten uzasnej, naprosto nejbezpecenjsi router na svete ... vydal uzasnou paradni aktualizaci ... ktera ho dokonale sejmula. Copak udela BFU? Mno pude reklamovat. Co udela prodejce? No posle to dodavateli ... a uz tohle stoji vic, nez ta krabka. A uz vidim ten nadhernej soudni spor, kdyz vyrobce vyda takovou aktualizaci po zaruce, a odmita uznat reklamaci.
btw2: Tech masin za miliony mas plnou halu, chces sledovat co se kde podelalo, a ne najmout 30 lidi, ktery to budou obchazet a zkoumat na lokalnich terminalech.
Sem si skoro jistej, ze porad najdes v provozu "CNCcka" programovany dratovanim.
Drátováním nevím, ale stále mám (byť velmi omezený) přístup k mašině na děrné pásky.
Pristup je danej smlouvou, pokud mas smlouvu na ktery dodavatel nic negarantuje, tak mas servis tomu presne odpovidajici = zadnej.
Ano, to dnes víme taky, že minulé vedení podepsalo nevýhodnou smlouvu, ale kdo by to byl tušil u zařízení v této cenovce, že.
Mimochodem je zajímavé, že tento přístup (ošetřit si vše smlouvou) nepoužíváš u těch tvých krabiček, které tě kdosi nutí každého půl roku vyměňovat. Proč si to smlouvy nedáš položku, že podpora musí být minimálně 10let? ;-)
Tech masin za miliony mas plnou halu, chces sledovat co se kde podelalo, a ne najmout 30 lidi, ktery to budou obchazet a zkoumat na lokalnich terminalech.
Tyto mašiny mají svou údržbu a revize, takže ty lidi stejně potřebuješ. Ne všechno se dá zvládnout od síťového terminálu.
Cena nevypovida zhola nic o kvalite.
To sice nevypovídá, ale současně člověk neočekává, že se ho snaží ojebat firma, co je na trhu několik desítek let a u zařízení v této kategorii. Kdyby se kupovalo něco na tržnici se slevou za 20Kč a ono to nefungovalo, tak neřeknu ani popel.
Společnost, ve které se budeme chtít všichni vzájemně ojebávat nemůže fungovat.
Staci, ze tu firmu posobiacu na trhu desiatky rokov niekto vecsi kupil alebo zmenila majitelov a s nimi sa zmenil aj pristup k zakaznikovi.
Ten dodavatel je aj vyrobca? Ak nie obratil by som sa na vyrobcu, zvykne to pomoct, hlavne ked dodavatel je nejaka tuzemska firma. Mam zle skusenosti s tuzemskymi dodavatelmi. Ty sa casto snazia zbavit zodpovednosti a tutlat veci. Ked kontaktujes vyrobcu, tak ma casto snahu riesit veci normalne.
Dnes cenova kategoria nic neznamema. Mam podobne skusenosti.
Drahe zariadenia maju vyrobnu vadu( neumyselnu, setri sa pri navrhu a testovani, alebo aj na odbornosti vyvojarov, ktory ich navrhuju) alebo sa setrilo na zlom mieste(najcastejsie napajacie zdroje so smejd kondenzatormi).
Mame tu teraz vahy za 1000-1500Eur kus, kde po tak zhruba 6 rokoch odchadzaju zdroje kvoli jednemu kondenzatoru. Dodavatel meni zdroje, ktory jeden stoji zhruba 150Eur.
My ich opravujeme - dlzka opravy tak pol hodiny + kondenzator v cene par centov. Starsie verzie vah tohto vyrobcu funguju veselo 15 a viac rokov bez poruchy.
Iny vyrobca vah, kde zdroje odchadzaju tak po 15 rokoch, bez problemov dodava sadu kondenzatorov na opravu.
Tak v tomhle pripade souhlasim s j.
Kdyz se prokaze, ze je sifra slaba, tak to jeste nema znamena, ze se zacne odstranovat ze softwaru, ktery se tvari, ze bez nej nelze zit, a ktery ma snahu se sam kazdou chvili aktualizovat.
Budes se divit, ale zrovna udrzba firmware je v prumyslu dost nezadouci.
Zakaznik vysoli 100M a chce, aby to fungovalo, aby ten stroj jel 24 hodin v kuse, udrzba aby tak maximalne dolila olej. On takovy stroj za 100M uz neni tak uplne seriovy stroj, spis to bude nejaka masina, ktera se na miste nejakou dobu (tydny? mesice?) davala do kupy a ozivovala.
Zakaznik rozhodne nema zajem na tom, aby mu tam co pul roku jezdil nejaky student od dodavatele upgradovat firmware a potom dva dny dohledaval, co diky upgradu zrovna prestalo fungovat. A to jenom protoze Google dokaze za rok na svem clusteru najit druhy dokument se stejnym hashem a tim padem je potreba z dohledoveho SW vyradit SHA1.
Nedej buh, aby si lis aktualizoval firmware sam po internetu.
Staci ze musi jednou za rok zaplatit za nejakyho drahyho nemeckyho smudlu v monterkach, ktery tam priletel do Prahy, autem prijel k zakaznikovi a ma den na to, aby stihnul odborne rozebrat a vycistit tri stroje a nejpozdeji druhej den uz zase jel zpatky, aby stihnul letadlo.
A s tou aktualizaci. Myslis, ze kdyz jedes s autem na pravidelny servis (za predpokladu, ze mas nejake chytrejsi auto), tak ze ti tam krome oleje a brzdovky sami vymenuji i firmware? Ne ze by to nebylo mozne, ale dost bych se divil. A co se tyka dieselgate, tak tam bych to snad ani nechtel, radsi kdyz to bude jezdit, nez kdyz to bude splnovat nejake urednicke euro 123.
Píšete v příliš obecných pojmech, proto jste se do toho zamotal. Buď máte nějaký jednoúčelový firmware, který řeší jednoduché věci. Není tam žádný HTTP server natož nějaké SSL. SHA-1 tam třeba může být jako ověření pravosti přenášených dat, která se posílají třeba po sériové lince. Pak je vám ale úplně jedno, že nějaký webový prohlížeč neakceptuje certifikáty podepsané SHA-1, protože mezi webovým prohlížečem a tím zařízením není vůbec žádná souvislost – to zařízení nekomunikuje ani po TCP/IP, natož aby komunikovalo přes HTTPS.
Nebo máte zařízení, které má být dostupné kde komu, takže se s ním bude komunikovat přes webový prohlížeč. Pak v takovém zařízení musíte mít implementovaný TCP/IP stack, musíte tam mít implementovaný webový server a SSL. Pak ale samozřejmě musíte počítat s tím, že se to zařízení bude průběžně upgradovat, protože nikdo nemůže tvrdit, že napíše bezchybný software, ve kterém implementuje TCP/IP, HTTP a SSL v takové kvalitě, aby bylo bezpečné ještě za deset patnáct let.
Pokud někdo koupí zařízení za 100M pro provoz 24×7, do kterého někdo zbastlil jakousi podporu TCP/IP, HTTP a SSL, u které se s žádnými upgrady nepočítá, tak musí zajistit bezpečnost toho zařízení, tedy ho musí vyčlenit do chráněné sítě, ve které bude vedle tohoto zařízení ještě speciální počítač se speciálním softwarem pro management toho zařízení. Tedy opět nic, kde by se vyskytoval běžný webový prohlížeč, kterým brouzdáte po webu, nakupujete v eshopech, čtete e-maily a používáte internetové bankovnictví.
Nebo-li to vaše zařízení za 100M a běžný webový prohlížeč se nikdy nepotkají ani v jedné síti, natož aby spolu komunikovaly. Pokud někdo stroj za 100M, který má běžet 24 hodin v kuse a který se uvádí do provozu týdny nebo měsíce, konfiguruje z webového prohlížeče, ve kterém má na dalších záložkách YouTube, Facebook a Novinky, pak pro něj nedostupnost kvůli SHA-1 bude ještě velice levným varováním, že něco dělá hodně špatně.
V podstate mate pravdu, obvykle to je skoro jako vase varinata 3. HTTP tam je, protoze dle managementu (at uz dodavatele nebo zakaznika) "stav zarizeni musi jit sledovat mobilnim telefonem". Samozrejme tomu odpovida kvalita, tedy "hlavne at to tam je". Zaplatpanbuh to nejspis nikdo do ethernetu nepripoji.
Ale zpakty k "Tobě přijde normální, když si firma objedná za 100M mašinu, z daní ji odepisuje 10 let a po třech letech už se s ní nedá komunikovat, protože dodavatel na to hází bobek?" Budu se opakovat. Ale me neprijde normalni, ze se s ni neda komunikovat a prijde mi normalni, ze se neaktualiyuje firmware kvuli kazde blbosti jako je prolomeni SHA1.
To ale není pravda, že se s tím zařízením nedá komunikovat. Nedá se s ním komunikovat s aktuálním prohlížečem. Jenže když máte zařízení, které má nezáplatované bezpečnostní díry, tak k němu určitě nechcete přistupovat přímo z běžného webového prohlížeče. Buď použijete nějaký speciální prohlížeč, nebo mezi to zařízení a prohlížeč postavíte nějakou bránu, která bude provoz filtrovat, aby se k tomu nezabezpečenému zařízení nedostal nějaký útok.
A to je prave to, v cem se proste neshodneme. Kdyz se k tomu dalo pripojit beznym prohlizecem pred deseti lety, tak proc se tomu nemelo jit pripojit beznym prohlizecem ted. Zvlast kdyz se ten prohlizec jmenuje porad stejne, jen se zmenilo cislo verze.
I kdyz uznavam, ze treba ve sveta PLC je jasne, ze 15 let stare PLC nenaprogramuju soucasnym SW, ale ze musim nekde oprasit stary NB s WinXP a starou verzi programovaciho SW. (Ani tak ne kvuli bezpecnosti, jako spis protoze nova verze SW uz nepodporuje starou radu PLC.) Ale programovani PLC povazuji za trochu neco jineho nez "kouknout se na www stranky zarizeni".
Protože špatně bylo už to, že jste se k tomu připojoval běžným prohlížečem před deseti lety. To, že někdo prohlížeč takhle špatně používá, není důvod, proč prohlížeč kazit všem ostatním. A bez toho kažení ostatním to bohužel nejde, protože jakmile budete mít v prohlížeči snadno dostupnou možnost přepnutí na nebezpečné protokoly, útočníci toho zneužijí.
Idealnim resenim by bylo vytvorit prohlizec, ktery by deklaroval, ze je zamereny na komunikaci s takovymito zarizenimi. Podpora vycpelych protokolu, zkazenych certifikatu (tak dlouho po maximalni dobe trvanlivosti preci nemuzou byt pozivatelne), a tak podobne. Nevyhoda soucasnych mainstreamovych prohlizecu je, ze nemuzete mit snadno dve verze na jednom pocitaci, aniz byste se bal o to, ze jeden prepise nejaka data z uzivatelskeho profilu pro ten druhy. Na druhou stranu, tohle by v dnesni dobe mohlu resit kontejnery nebo i plna virtualizace.
"Protože špatně bylo už to, že jste se k tomu připojoval běžným prohlížečem před deseti lety."
Ale vzdyt to je prece to. Ze nepotrebuju mit ke kazde blbosti na notebooku nainstalovanou konkretni konfiguracni aplikaci, ale ze to vsechno pujde z www prohlizece. V dnesni dobe z www prohlizece v mobilu.
Jak navrhuje ebik pode mnou. Udelat prohlizec, ve kterem se daji vsechny tyhle stare veci zapnout, tak jsem naprosto spokojen. Zabezpeceni at si resi ajtaci.
Jenže to je špatně, pokud k nezabezpečenému zařízení budete přistupovat univerzálním prohlížečem. Pak může být to zařízení přes prohlížeč snadno napadeno a odstaveno nebo dokonce zničeno. To si musíte rozmyslet – buď je to opravdu zařízení, u kterého si nemůžete dovolit výpadek, a pak se musíte postarat i o jeho bezpečnost a používat speciální bezpečný software. Nebo je pro vás důležitější pohodlí, nějaké výpadky a odstávky nevadí, no a pak by zase neměl být problém ho udržovat aktualizované. Ostatně psal jste, že to zařízení jednou za rok přijede seřídit nějaký technik z Německa – tak proč nechcete být stejně náročný i v softwarové části? Nebo proč nejste stejně benevolentní, jako u toho softwaru, i při řešení toho hardwaru – a když vám pro správu má stačit obyčejný prohlížeč, proč vám pro seřízení nestačí firemní údržbář, který se jinak stará o dveře, světla a topení, s pořádným kladivem?
A k tem zarizenim existuje nejaky specialni bezpecny software? Verte tomu, ze napriklad protokoly k ruznym PLC jsou fakt trivialni, nikde nemaji zadna hesla (respektive maji, ale nikdy je nikdo nenastavuje, respektive nastavuji se pouze u hodne podezrelych zakazniku). Paket pro zapis do pameti vetsiny PLC je fakt smesne jednoduchy. Jakmile se jednou pripojite do lokalniho ethernetu dane skupiny stroju a vite co a jak, tak muzete v podstate vsechno. Nejaka SHA1 je proti tomu o nekolik levelu vyse.
Kdyz technik z Nemecka v ramci udrzby neco mechanicky poskodi, tak se dost snadno prijde na to, co se stalo. U software mi to tak neprijde, respektive urcite na to neprijde ten technik z Nemecka, on je sice z Nemecka, ale v oblasti SW moc chytrej neni. (Kdyz uz ma s sebou notebook, tak jedine, aby nekde poladil nejake konstanty.) SW je ve srovnani s HW cerna dira, na kterou se pokud mozno nesaha, protoze jak se rika "V kazdem programu je chyba a opravenim jedne chyby vznikaji dve dalsi."
A jinak navrhuju to ukoncit, oba jsme evidentne v tomto stavu:
https://xkcd.com/386/
Nechápu, co se tu řeší. TLS 1.0 bylo definováno v roce 1999, SHA-2 v roce 2001, AES pak v roce 1998. RSA tu je hodně dlouho, ale až v roce 1997 bylo uveřejněno. Nějakou dobu trvalo, než byly implementovány v crypto knihovnách. Pokud by, řekněme od roku 2002, používali vývojáři kombinaci TLS_RSA2048_AES128_SHA256, tak by nebyl nejmenší problém s kompatibilitou s browsery na několik desetiletí. Podle aktuálního doporučení NISTu by taková kombinace měla stačit nejméně do roku 2030.
Jestli vývojáři SW pro mašinu za 100M, u které se předpokládá životnost několik desítek let, použijí crypto sady, které tak dlouho nevydrží, pak jejich problém. Není to problém vývojářů browserů a už vůbec to není problém ostatních uživatelů, které by podpora starých crypto sad ohrožovala. Není prostě možné kvůli skupině 0.001% techniků, kteří se budou k takové mašině připojovat, ohrozit zbylých 99.999% obyčejných uživatelů.
Buď by měla mít mašina za 100M adekvátní podporu a nebo je to prostě nutné řešit jinak. Například speciální browser pro konfiguraci a nebo nějaká MITM proxy mezi mašinou a browserem.
Minimálně od roku 2005 se ví, že SHA-1 je slabý algoritmus a od roku 2010 není doporučeno ho používat.
2lojzak ... Nechápu... no to vime ze ty nechapes, vubec nic ... rec totiz byla o tom, ze ani za desitky nebo stovky mega nedostanes to, co TY chces aby dostal kazdej BFU za stokoruny. A ten BFU tu svoji krabku za kilo pouzivat chce a pouzivat bude, muzes se z toho klidne posrat, muzes klidne chodit po usich, ale nic nezmenis na tom, ze ta jeho krabka pouziva to co ji dal vyrobce do vinku a NIC jinyho NIKDY umet nebude.
Muzes mu tak maximalne umoznit pouzivat maximum co mu jeho krabka umozni, ale kdyz mu to vemes, tak on proste bude pouzivat TO, co JEMU funguje, a to je v tomhle pripade stara verze browseru se zakazanou aktualizaci, protoze to je presne to, co dela co on chce.
@j
"no to vime ze ty nechapes, vubec nic "
Kdo my? Je vás víc a nebo používáš pluralis majestatis?
"rec totiz byla o tom, ze ani za desitky nebo stovky mega nedostanes to, co TY chces aby dostal kazdej BFU za stokoruny."
To je ale pak problém kupujícího, že si neumí vybrat pořádné zařízení. Minimálně od roku 2002 mohou výrobci zařízení použít pro HTTPS šifrovací sady, u kterých se ví, že budou spolehlivě fungovat s aktuálními browsery nejméně do roku 2030. Ale holt když jsou někteří vývojáři pitomci a nepoužijí adekvátní zabezpečení, tak trpí i zákazník.
"A ten BFU tu svoji krabku za kilo pouzivat chce a pouzivat bude, muzes se z toho klidne posrat, muzes klidne chodit po usich, ale nic nezmenis na tom, ze ta jeho krabka pouziva to co ji dal vyrobce do vinku a NIC jinyho NIKDY umet nebude."
Já mu tu krabku za kilo neberu. Já jen nechci, abych byl ohrožován přitomností slabých protokolů a algoritmů v prohlížeči, jenom kvůli nějakému joudovi, který si koupil krám, co nic neumí.
Kolik uživatelů browseru potřebuje přistupovat na špatně zabezpečená zařízení? Asi tak 0.01%? A kvůli tomu má být ohrožována majorita?
"Muzes mu tak maximalne umoznit pouzivat maximum co mu jeho krabka umozni, ale kdyz mu to vemes, tak on proste bude pouzivat TO, co JEMU funguje, a to je v tomhle pripade stara verze browseru se zakazanou aktualizaci, protoze to je presne to, co dela co on chce."
No vidíš, že to nějak půjde. Když chce používat starý browser, jeho blbost.
Víš milé "jéčko", udivuje mě na tobě jaký jsi liberál ohledně podpory slabých crypto protokolů a současně jaký jsi diktátor třeba ohledně IPv6. Chtěl bys třeba, aby Google vypnul IPv4 jakmile dosáhne 6 alespoň 30%. Tady ti nevadí, že některé "krabky za kilo" nikdy IPv6 umět nebudou? Jak si mám vysvětlovat takový názorový protiklad? Trpíš schizofrenií? Tím by se vysvětlovalo, proč o sobě mluvíš v množném čísle.
Jisteze, trotl jako ty samo nemuze vedet, ze ipv6 je z roku 1995, to je nejakych jen tak mimochodem (protoze pocitat taky jiste neumis) 22 let.
Nevsim sem si ze by nekdo vypinal sifrovani, ktery se 22let nepouziva, zato sem si vsim, ze se kreteni jako TY snazej vypinat veci, ktery se pouzivat jeste peknych par mesicu nebo let budou.
A ta jeho blbost je tvuj problem, protoze prave trotl jako TY tu pak bude brecet, ze mu na tu jeho jednu IPv4 za kterou ma pres 4 NATy 10k lidi ... tech 10k lidi s tema starejma browserama utoci, protoze chtej aby jim fungovala jejich lednice.
@j
No vidíš, zhruba ze stejné doby pocházejí protokoly a šifrovací sady, které bude možno bezpečně používat až do roku 2030.
"Nevsim sem si ze by nekdo vypinal sifrovani, ktery se 22let nepouziva, zato sem si vsim, ze se kreteni jako TY snazej vypinat veci, ktery se pouzivat jeste peknych par mesicu nebo let budou."
Pokus se to přeformulovat na srozumitelnou větu.
"A ta jeho blbost je tvuj problem, protoze prave trotl jako TY tu pak bude brecet, ze mu na tu jeho jednu IPv4 za kterou ma pres 4 NATy 10k lidi ... tech 10k lidi s tema starejma browserama utoci, protoze chtej aby jim fungovala jejich lednice."
Jéee, to je vtipný, jak ses do mě pustil. Jenom nechápu, jak jsi přišel na to, že jsem odpůrce IPv6. Takže sis zbytečně vyplýtval jedy.
Ty jsi totiž nepochopil, že jsem chtěl poukázat na rozpor ve tvých názorech. Na jednu stranu bys chtěl, aby browsery podporovaly všechny staré crypto sady, i když to je nebezpečné, ale na druhou stranu bys všem hned vypínal IPv4.
Nikoli, to jen negramot jako ty nedokaze pochopit rozdil, navic mas zjevne kristalovou kouli ze si dovolujes tvrdit, ze neco bude mozny pouzivat jeste dalsich 13 let ... lol
Mam tu krabku starou 15 let ... a ... zazrak ... ipv6 ... umi. I win XP ipv6 umej, sice blbe, ale uplne stejne blbe jako win 10. Dost pochybuju, ze ma kdokoli doma cokoli, co ipv6 neumi.
Zato denne resim to, ze se neda na nejakou z tech krabek pripojit, protoze browser prohlasuje, ze to neni bezpecny a tvrdi mi, ze kdyz to heslo poslu pres http, je to naprosto OK.
@j
Tak ono se dost věcí ví dopředu. Taková doporučení NISTu ohledně šifrování jsou poměrně spolehlivý ukazatel. A třeba o SHA-1 se ví minimálně od roku 2005, že je více náchylná na kolize, než se myslelo. Od roku 2010 se podle NISTu nemá používat vůbec, pokud by měla mít bezpečnostní funkci.
Vysvětli mi, proč by měl výrobce těch krabek používat z hlediska bezpečnosti překonanou hašovací funkci, když existuje adekvátní náhrada.
"Mam tu krabku starou 15 let"
No vidíš, když jsi před 15 lety dokázal vybrat krabku, která v pohodě umí IPv6, tak proč nevybereš takovou, která podporova adekvátní crypto sady, u kterých se ví, že i v budoucnu budou podporované.
"Zato denne resim to, ze se neda na nejakou z tech krabek pripojit, protoze browser prohlasuje, ze to neni bezpecny a tvrdi mi, ze kdyz to heslo poslu pres http, je to naprosto OK."
A já zase doma nemám ani jednu krabku, kde by byl problém s šifrováním, ale zato mám spoustu krabek, které neumí IPv6. A na rozdíl od tebe nebrečím, že mi něco nefunguje, prostě příště vyberu lépe.
Ještě jednou ti zopakuji pointu. Kdyby výrobce nějaké té krabičky od roku 2002 používal kombinaci TLS 1.0_RSA2048_AES-128_SHA256, tak nemáš nejmenší problém se i teď, po 15 letech připojit. A zřejmě nebudeš mít problém ani v budoucnu.
A taky si uvědom, že jsi menšina. Jenom pár lidí se potřebuje připojovat ke krabkám se slabými crypto sadami. Majorita se ti přizpůsobovat nebude, zvláště, když by to znamenalo bezpečnostní riziko. Stav se třeba na hlavu, ale nic nezměníš.
Buď používej starý browser a nebo si udělej nějaký vlastní. Hlavně prosímtě přestaň s tím brečením.
Na kurzech ekonomie nam jeden pan rikal ze to jsou firmy typu "Trhni a Zdrhni".
Vase firma nezna neco jako support contract po dobu odpisu? Ze by knedlikove IT a management? U nas se objednava aspon na 5 let u levnych veci cca do milionu, u drahych veci za desitky a stovky milionu do tovaren i na dele(ano delame to lip, zadna skromnost). Nicmene pro nektere specificke a zanedbane technologie tohoto typu se drzi nekolik dedikovanych HW se starou konfiguraci do zasoby a custom support kontrakty klidne s NTcky,XPcky nebo starym OS2 a cekaji se az dozijou. 10 let neni zas az tak dlouho. Obvykle v praci resim horsi zombie.Je to takova moje profesni specialita;)
Prikladem ktery mne napada od nas z CR a blizka beznym smrtelnikum.budiz bankomatova sit jedne vyznamne instituce ktera snad jeste i nyni jede na NTckach 4.x.
Hele, v jiných diskusích odpovídáš rozumně, tvůj slovník + znalosti je tady svým způsobem unikátní kombinace, tak si to nepokaž. ;-)
U některých funkcí se to ví tak dlouho dopředu, že se mezitím stihla vystřídat celá jedna generace hw, takže je skoro s podivem, že si někdo dokáže vybrat takový, který nepodporuje nic novějšího.
Aktuálně lze mít kontinuálně od roku 1999 (TLS 1.0) až dodnes stále jeden šifrovací standard (pokud to tehdy někdo udělal dobře), protože dodnes bezpečná sada šifer existovala již tehdy (ok, možná bude potřeba natáhnout velikosti klíčů). Což je 18 let.
To asi tak celé, co jsem chtěl napsat k tomu "každého půl roku kupovat nový". Sám víš, že to není pravda, o všech funkcích se to vědělo roky dopředu a žádná novinka to není.
To jiste ... 99 rikas ... chmm DD-WRT (11/02/2009) ... cannot be shown because the authenticity ...
Ta vec normalne funguje a dela exaktne to, co delat ma. (s open wrt to dopadne exaktne stejne, jen ta verze bude o cca 2 roky starsi). Http funguje ovsem bez potizi, takze se prave bfucku reklo "v zadnym pripade nepouzivej https, protoze to nefunguje".
Jo a ... staci se rozhlidnou po rootu ... to je taky paradni ukazka. Js nacitajici http, pripadne deravy https ...
1. Kolik BFU používá a administruje WRT?
2. DD-WRT je trochu out, na svůj router v dílně nemám novější verzi, než 2012. Takže to bych jako relevantní argument moc nebral... Navíc DDčko je pro ty nejosekanější obludy, kde prostě na nic není výkon ani paměť.
3. OpenWRT je celkem živý projekt a SHA-256 používám naprosto standardně.
Nebude problém v tom, že si koupíš HW za pětikilo, narveš do toho alternativní FW co je pár let v klinické smrti (protože kdo verzi pro tvůj router stvořil, ten už si koupil něco lepšího a na podporu šrotu kašle) ? Když k tomu přidám tvou snahu vyrovnat se BFU (=předpokládáš, že si BFU flashne router) a že svou neschopnost a předpokládáš u všech ostatních, tak se nedivím, že reaguješ jak reaguješ.
Kazdy jedno BFU ma dome nejakou krabku na internet, na ktery potrebuje obcas neco nastavit, kazdy jedno BFU ma doma televizi, kterou rozhodne pristich 15-20let bude pouzivat, velmi brzo to budou lednice, mikrovlnky, pracky, mycky atd atd.
Jiste, tenhle routrik stal svyho casu jen cca 3k5 - teda dovoz z nemecka, u nas cca 5k, coz v soucasnych cenach odpovida rekneme 8k. A novejsi firmware pro nej neexistuje. Teda samo, moh bych si pripadne prekompilovat svuj, ale proc bych to mel delat, a specielne sem zvedavej, jak to bude delat to BFUcko, protoze to tam necha firmware vyrobce, kterej vyjde naposled v nejlepsim pripade 1/2 roku po nakupu. Jo, v tomhle pripade na to vyrobce vydal aktualizaci jeste rok potom, co to prestal vyrabet, precijen je to sice domaci hracka, ale cisco ...
A uz vidim jak zivy, jak si nekdo kupuje krabku na internet za 50k ... aby to mel s 5 lety supportu. A jestli tu nekdo predpoklada flashovani routeru, tak to ses leda ty.
Mikrotik stojí 50k? A třeba jako WiFi AP se dá kidně použít nejmenší OrangePi, a nějaký aktuální klon Debianu seženeš vždycky.
A co se odbornosti týká, tak každý řidič má něco, co je potřeba jednou za čas seštelovat - brzdy, předstih,.. Když to neumí, dá to do servisu. Takže to, že mám nějakou věc, potřebuju jednou za čas s tou věcí něco udělat a neumím to, není argument. To stejně můžu namítnout, že neumím v autě seštelovat posilovače, tak zakážu všechno novější než Žigulík.
Mikrotik nestoji 50k a taky nema zadnej support. To sem si takhle sel opatchovat mikrotika, a prestala fungovat vpn(jo, opravili to, za dalsich 10 verzi). Jindy zaclo padat dhcp ... opet, ja si poradim, BFU je v haji. Proto vyrobci zadny aktualizace nevydavaj, protoze to nehodlaj riskovat. A proto ja ani toho mikrotika neaktualizuju, protoze se stim nehodlam babrat.
Co funguje do toho se nehrab - zlaty pravidlo kazdyho svepravnyho admina.
BTW: Bez se zeptat nejakyho wifinare, co ma desitky mikrotiku v siti, jak je aktualizuje, urcite ti nadsene poreferuje.
A jaký je pode tebe kritérium pro "funguje"?
a) BFU se dostane na web. Ale díky natování je to všechno, co zvládne. Funguje taková síť?
b) Síť nepodporuje IPv6. Je taková síť na 100% funkční?
c) Zákazník očekává přenos zprávy zašifrované tak, že nikdo mimo něj a příjemce zprávu nepřečte. Je zařízení funkční (z pohledu splnění požadavků zákazníka), když použije prolomenou šifru?
d) Zákazník si platí řekněme 20Mbps, z toho 18Mbps pro sebe používá spambot díky 0-day v routeru a zákazníkovi se seká fotbal v telce. Je to funkční služba, za kterou si zaplatil?
e) Nedávný útok na nezáplatovaný Ubiquity. Byla to funkční síť? Admin do ní přece roky nehrabal... než musel sednout do auta a objíždět každou krabičku.
Myslím, že už jsi dneska nakrmený dost...
ma doma televizi, kterou rozhodne pristich 15-20let bude pouzivat
Tak televize má snad vlastní rozhraní ne? I s monitorem :-D
Akorát s těmi 15-20 lety bych to neviděl tak optimisticky, protože ti zruší vysílání ve staré normě a jsi víš kde. Kodeky jsou HW, takže žádný update firmware z h264 neudělá podporu pro h265.
A jestli si někdo pořídí mikrovlnku s https rozhraním, tak je to asi jeho problém. To zařízení nemůže bejt jednodušší (HV trafo, magnetron, časovač), to vydrží věčně, a jestli někdo má potřebu si tam nechat zamontovat i celý komp, tak mu asi není pomoci. (Jinými slovy nechápu, proč by zrovna mikrovlnka měla být připojitelná na počítačovou síť.)
Přesně tak, digitálně podepisované či datovou schránkou posílané dokumenty by měly být tak jednoduché, jako ta mikrovlnka. Čili žádné PDF, DOC, JPG, ale plaintext. Kdo by chtěl vytvořit kolizní dokument s jiným textem, ale stejným hashem, by pak musel v textu zvolit a pak permutovat dvacítku znaků, což se v prostém textu nepozorovaně provésti nedá.
"Tak televize má snad vlastní rozhraní ne? I s monitorem :-D"
To ma, a taky ethernetovej konektor a webovy rozhrani. A k nemu se bud muzes pripojit pomoci browseru, nebo treba pomoci appky ze svyho mobilu. Nesifrovane, protoze telku ktera by provozovala vubec nejaky https sem jeste nevidel. A vyrobci zjevne dobre vedi proc.
1/2 domacnosti stale minimalne jako sekundarni provozuje CRT ... s nejakou krabkou.
Jisteze je to jeho problem, on se podle toho zaridi, bude pouzivat tu verzi browseru, se kterou mu to funguje. A s nim dalsich par miliard lidi. A tady se pak bude probirat, jak vyresit ty miliardy zombiku co zahlcujou net. A to vsechno proto, ze sme tomu BFUcku ve jmenu bezpecnosti ... zakazali ty ... nebezpecny sifry.
> Aktuálně lze mít kontinuálně od roku 1999 (TLS 1.0) až dodnes stále jeden šifrovací standard (pokud to tehdy někdo udělal dobře),
Hodně teoreticky. Nejde jen o implementační chyby, TLS 1.0 má návrhové chyby, ke kterým existují workaroundy. Namátkou BEAST (pravda, tady je správný workaround na straně klienta*) nebo padding oracles, pokud pošlu chybové hlášky přesně podle podle specifikace (AFAIR by se mělo rozlišovat mezi bad padding a bad mac, což není bezpečné). A věřím, že toho bude víc.
Čímž nerozporuju poslední odstavec.
*) RC4 je workaround na straně serveru, ale víme, kde je dnes RC4…
A když jsou funkční výrazná zlepšení systému CA, tak zase remcáš, aniž bys řešení vůbec pochopil...
https://www.root.cz/clanky/google-zverejneni-tls-certifikatu-bude-za-rok-povinne/nazory/
U šifrování jsou legacy algoritmy a protokoly problém. Vzpomeňte si třeba na DROWN. Legacy SSL2 moc lidí netrápilo, protože to přece žádný rozumný klient nepodporuje… Nebo POODLE – už dávno se SSL3 moc nepoužívalo, ale útočník mohl udělat downgrade spojení na SSL3, takže onen legacy algoritmus snižoval zabezpečení.
Jakou navrhujete alternativu k zaříznutí nebezpečných algoritmů a protokolů? Má se podporovat všechno donekonečna, i když to není bezpečné? Co tím získáte? Leda falešný pocit bezpečí, že vám funguje HTTPS s legacy strojích. Ale takové HTTPS dříve nebo později nebude zaručovat nic. A to nejen u těchto legacy strojů, ale ani u serverů, kde se na bezpečnost dbá.
Legacy stroje, kterého nedostávají žádné aktualizace, je těžko udržet bezpečné – nejenom kvůli HTTPS, ale mohou tu být různé jiné zranitelnosti, kterými útočník může třeba až vykonat libovolný kód. Ale pokud bych se měl snažit s tím legacy crapem udělat, co umím, tak reverzní proxy je poměrně jednoduché opatření, které vyřeší kompatibilitu a trochu i bezpečnost.
Možnost to povolit pro danou doménu je ještě relativně rozumná. (I když: proč tu vlastně chcete HTTPS, když zároveň to nechcete pořádně zabezpečit? Co zde HTTPS přinese? Stojí za to zde učit uživatele odklikávat chybové hlášky?)
Automaticky akceptovat nevyhovující spojení ale není dobrý nápad – to může snadno leaknout URL nebo cookies atd. v tomto stylu: http://www.lamer.cz/quote/50132
"Na stovce grafických procesorů tak dokážete vytvořit kolizní dokumenty během jednoho roku"
Tedy chapu to dobre ze jeden rok je prumerna doba hledani kolize? A vi nekdo jak priblizne vypada pravdepodobnstni rozdelovaci funkce te doby (histogram)? Je to rovnomerne nebo normalni, rozptyl?
ja mel spis na mysli dobu hledani kolize pro dany konkretni dokument (a ne dobu hledani jakekoliv kolize).
proste chci provest utok (podvrhnout dokument), podle clanku mam pocitat s jednim rokem hledani kolize. je ta doba jednoho roku prumer? jaka ma ta doba rozdeleni (neboli jakou mam sanci ze kolizi najdu uz po jednom mesici)?
tady je druhá ;)
$ sha256sum helloworld*.pdf
2933526acbb85042d5b1df3c4d6aee9671a048562a0f0a4907d66b1134512311 helloworld1.pdf
51bdd1bf1a1418728f71586ad1411ea8eda56790e2f7f4b3f820c36a917fa72d helloworld2.pdf
$ sha1sum helloworld*.pdf
a0cad1957a3369ed5d624bacd291837924da1a58 helloworld1.pdf
a0cad1957a3369ed5d624bacd291837924da1a58 helloworld2.pdf
respektive n-tá.. on už to není problém vyrobit, akorát ty vzniklé soubory jsou v podstatě k ničemu.
tak tady jsou (trochu jiné, optimalizoval jsem velikost o pár řádů)
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/BJhdADQZSe6OHIvlLjRrQut+GFRfRrV6BtQUxwHH wq/efF2SoDVGopo35pev/MFFDCa769tBMG/xbcfAgJtj4PBl4AgBF2MPCmoRwifT00sXvyZL1YeZ l9CNdyjpJzd7hrzSVr/xhP8lk801Qo5iWmn347V+wJn2UDfx8oV25FbE/eFHODvdAZfS2Tx7PCaV QaM5AirKpY32ZZ2VzhliaMt8atUANHc+4Xk8f0MfuUxoPr2sTZEe4KUwlr4BCn0SxaPUfnTDIR16 MJSWewHVSEftCFyMwDd6PSkP3pBmEiKINlkRKQ1Icylm4eelGCE9BkCKlizM8LbNjTgRw5sdrLFz VqsTCQYav7UOXROo235FPkpaN4I8KyMgUOX4zS52Sm/UpfOmwPTKhi8ZJd8dL8tW3RdknPXoZuy8 5wdcS1kAGT1+SUzSbzl5v3Ffu79RFZK0AQCLcXaKqLAH7RtQmbG9fgvU8oU0ToobhZNzkEiv5t2J 30FPHAXzhkNyIKtIpOMdFX4geJaOlxYHQyvDkygrzeckAaBmUThXO/cb2UOnQpMdBf39/I2rJN/m Mzo4SPpX4ta1Rv1uqgqyApF8V9Oz/w8Q/6JT6LrFdqMoxjwCxCdo6aoQauRTwnTKDiP0iNXHGQie VyGqILEM5j/DeA5KtyAf+k0nGR9Lgqm1LTIoViZuCBmJBnnfTmLeoj0fw+TrFlkUU1spVZfbK3O9 o36YFTx9/+3I/MR0gQa7UEfoedGzYFsv3vLbhJx5a4D+4ZAan5HORXJXQO1Vhxiv/s5Q32vrGue9 mDrVCTF61q/lo+gwC6f2dlNj8HYUPJQZGk6/zqUdWTosPtPUhdIpNYu+5nDq28OKDPfBi45bEBoZ Bj/6+2+kqZ4icma8sadfkmUIM/pIQF6P81ZMhgUxj6PIb/5GT97kwwcSLGAiAQUCX7Ys83JXHtiZ FOAQgG50bJ218wYtPFmO50wCMJ+FuqxCw7c2XspzFuS3Iw2+HDCpf6nCxCBKgVoVrTJvE/fHdrer oR3IZ2sQDc5dIPRuhtI6Nora4aRqfK0Ac2d1/KFu3P7ze3GI1XaiV/W8OlEOkgoMePDPF3929EZn cQfFkwjujSY0pJW7J841S/E/+hjmj6EmOtXgivxXPXvVbhGFQ6No6fWff1sNf1TzECwgQIbD424G Ix3kZ7/dln/qkS1LFB21MdOw6xFMpm7C1eeQAMfFB/B8p0s2w3JEhp65awGd83JL+hdgIs/rZG6v fG9Pg2WERlk2Jfsq+MJqNXeRyYHa5b6IyzwGlc0xPk0c0uEJgBICmpzHVuty/P36wonv45AMhkWL GSB5wYzhLOd2G9H4TS/PUWsA12dvQndts67t123dflTqOMjoCaSlHrJJ+BRpPiYqCV3Ds44GM/jJ 2M2HlfLa7wxmhNaj5VdEO6TGicUHyAd5zDQ0e/f5JDrxxvExFzhHUDLeQnteL7zPNqlHBHo/Suyk HtevTfbmsJotGWXiGdCygP8QpznmRwnvmxN5PEAWZhXU+y5AI35N2YGPsl0MUz09yhsGt152ck4g JgYzf41VLG5eAABvrK3+GMlOGwABtAmAUAAARH/7zrHEZ/sCAAAAAARZWg==
Vlastně ne tak docela – naivní přístup by díky narozeninovém paradoxu po nějakém čase kolizi jistě našel. To už není exponenciální rozložení. Pokud bychom ale vybírali vstup pro další pokus náhodně, k exponenciálnímu rozložení bychom se přinejmenším přiblížili. Ale každý další prvek by měl o něco větší šanci kolidovat s něčím jiným již známým.
Intuitivně ale exponenciální rozložení dá optimističtější odhad ohledně brzkého nalezení (tj. před očekávanou dobou hledání), takže by zde mohlo z pohledu potenciální oběti posloužit jako pesimistický odhad.
A co platí pro tento útok, to je otázka. Přijde mi zajímavé, že jsem zatím neviděl nic o prostorové složitosti, která by byla při uložení 9e38 preimages značná.
Kolizní část těch souborů má dva bloky, a už po prvním bloku se stav přiblížil. Kdyby tyto dvě fáze probíhaly odděleně, stále je potřeba prostor pro aspoň 4.5e38 preimages. To je sice čtvrtina (preimage zde má pouze 64B namísto 128B), ale pořád mi to přijde dost na to, aby to stálo za zmínku.
Pokud mám dvě funkce F a G, který jsou na sobě nezávislý a chci najít čísla A a B tak, aby výsledky byly stejný, dostanu se na soustavu rovnic
F(A)-F(B) = 0
G(A)-G(B) = 0
A při tom samozřejmě platí i vztahy
F(x) = y, G(x) = z
Tím se dostaneme 2D prostoru (najdi x pro dvě stejný y) do 3D prostoru (najdi minimálně dvě x, modu se souřednicí [?, y, z]). A to už je o poznání jinde.
Tímhle přístupem můžete dokázat, že MD5 i SHA-1 jsou stále bezpečné. Útok na obě dvě hashovací funkce ale spočívá v tom, že se nemusí počítat všechny možné kombinace, ale v té funkci byla nalezena jakási „zkratka“, takže těch možností, které je potřeba prohledat, je řádově méně. Protože MD5 i SHA-1 jsou ze stejné rodiny hashovacích funkcí, je možné, že bude existovat i nějaká „zkratka“, kvůli které nebudete muset porovnávat každou variantu MD5 s každou variantou SHA-1.
Žádný takový útok v současné době znám není, ale také ho nikdo nehledal. „Síla“ MD5+SHA-1 tedy nespočívá v tom, že by to byl silný algoritmus, ale prostě nikomu zatím nestálo za to to podrobit analýze. Je to velmi podobné tomu, když si někdo nějakou šifru nebo hashovací algoritmus splácá sám.
Každopádně používat dohromady MD5 a SHA-1 by se mělo jedině v případě, kdy opravdu není žádná jiná možnost. Nechápu, proč je tahle varianta v článku uvedená před SHA-2. Mělo by tam být, že je potřeba používat alespoň SHA-2, pokud to nejde, tak znovu řešit, jak použít SHA-2, když to opravdu nejde, tak to zkusit ještě jednou, a teprve kdyby neexistoval žádný způsob – tak už bych klidně zůstal u SHA-1, protože to stejně nemůže být nic kritického a z případné kolize nebude žádná škoda.
Jasně. Obecně se přeneseme z hledání průsečíku přímky s křivkou na úroveň hledání průniku přímky s plochou.
Ale pokud dokážeme jednu souřadnici určit, jsme zpátky v rovině a zase hledáme jenom tu křivku místo plochy.
A jsou tam i další zrady, například SHA-1 má výstup 160b, Výstup MD-5 je 128b. Když spočítám výsledný počet kombinací, tak se dostanu na zdánlivých 288 bitů. Z toho ale 128b se dá rychle prolomit... SHA-2 je tak, i přes menší počet bitů, bezpečnější.
> Je to velmi podobné tomu, když si někdo nějakou šifru nebo hashovací algoritmus splácá sám.
Hashovací funkce h(x) = sha1(x) md5(x) bych přirovnával spíše k 3DES než k něčemu úplně home-made. (A ani 3DES není uplně dokonalé přirovnání.) Lze snadno dokázat, že je odolná kolizím minimálně stejně dobře jako ta lepší ze dvojice funkcí SHA-1 a MD5. (Umíte-li nalézt kolizi pro h, najdete takto kolizi pro sha1 i md5 současně.) To sice není kdovíco, ale pořád bych tomu věřil řádově více než něčemu úplně home-made. Z hlediska jiných útoků už je argumentace někdy o něco složitější, ale i tady bych tomu věřil řádově víc než úplně home-made funkci.
Pravda, kombinace SHA-1 a MD5 není úplně šťastná, protože obě funkce jsou Merkle–Damgård, obě mají stejnou délku bloku (512b) a obě mají snad i na chlup stejný padding. (Na padding jsem se díval v rychlosti, takže jsem nějaký rozdíl mohl přehlédnout.) Takže stačí „jen“ najít společnou kolizi v kompresních funkcích, a mám hotovo. Ale to asi nebude úplně snadné.
Uznávám taky, že ne vždy kombinace dvou funkcí pomůže. Někde jsem viděl útok na kombinaci MD5+CRC32. Fungovalo to přes tzv. multikolize, kdy (zjednodušeně řečeno) nalezením n kolizí v kompresní funkci vyrobím 2^n kolizí (2^n hodnot, kde všechny mají stejný hash). Když tedy skrze multikolize vyrobím 2^33 hodnot se stejným md5 hashem (při výkonu smartphonu to trvá orientačně 33*0.5 minuty = 16.5 minuty), mohu ve výsledcích hledat kolizi CRC32 hrubou silou a jistě ji tam najdu. Ironicky bude fáze hledání kolize CRC32 trvat nejspíš déle než hledání multikolize pro MD5, protože u CRC32 by případný rychlejší postup těžko zohlednil, že chceme současně kolizi MD5.
Podobný postup u SHA1+CRC32 už se trochu prodraží, i kdybychom chtěli prohledat „pouze“ 2^16 hodnot a doufat, že to u CRC32 vyjde.
U SHA1+MD5 by to teoreticky šlo, pokud akceptujeme cca poloviční šanci na úspěch* a obrovské náklady:
1. Nalezení multikolize SHA-1 (řekněme, že by nám stačilo 2^64 hodnot, tj. 64 kolizí, výměnou za cca poloviční pravděpodobnost úspěchu) by se prodražilo (řádově 6.4 milionu USD), i když by asi nebylo mimo realitu.
2. Projít 2^64 hodnot a najít zde kolizi MD5 by se prodražilo, i když by asi taky nebylo mimo realitu. Je to ale náročné nejen časově, ale i prostorově.
3. Výsledná kolize by byla 128 bloků dlouhá, tj. 128*64B=8KiB. I toto by někdy mohl být praktický problém.
Nemohu se ale ubránit pocitu, že pokud toto bude moje nejslabší místo, tak jsem na tom ještě dobře. Zkuste cenu tohoto útoku porovnat s cenou různých 0days. Navíc zde předpokládám, že kolizi kompresní funkce takto dovedeme počítat pro libovolný prefix, což se může po odhalení detailů útoku ukázat jako největší praktický problém.
Ale jinak samozřejmě doporučuji použít SHA-2 radši než MD5+SHA1. Kombinace MD5+SHA1 má smysl pouze v případě nějakých legacy záležitostí apod.
*) Díky narozeninovému paradoxu by pro poloviční šanci na úspěch mělo stačit prohledat cca 2^(n/2) hodnot, ačkoli prosím jistou kolizi potřebuju prohledat 2^n+1 hodnot.
Ano, home-made asi nebylo nejlepší přirovnání. Myslel jsem ty případy, když někdo začne amatérsky „vylepšovat“ nějakou kryptografickou funkci (použije jí opakovaně, do výsledku přimíchává globální klíč apod.), má pocit, že výsledek učinil řádově bezpečnější – a přitom se o výsledku jeho snažení dá prohlásit nanejvýš to, že není horší, než ta původní funkce, ze které vyšel. Pravda je, že tyhle pokusy často končí oslabením původní funkce, což není případ spojení MD5 a SHA-1.
Podstatou mého komentáře bylo to, co jste napsal dál – že o kombinaci MD5+SHA1 dnes víme akorát to, že není horší než lepší z těch dvou funkcí, v současné době tedy SHA1. Tedy použitím MD5+SHA1 dostanu stejnou bezpečnost, jako použitím samotného SHA1. Tedy přidáním MD5 se bezpečnost nezvýší, zvýší se jenom iluze bezpečnosti, což je vždy nebezpečné – protože se dotyčný nejspíš nechá ukolébat tím, že pro bezpečnost něco udělal, místo aby rovnou řešil přechod na SHA-2.
> Tedy přidáním MD5 se bezpečnost nezvýší
Podle toho, co víme dnes, to vypadá, že se bezpečnost zvýší, byť ne o tolik, kolik by si někdo mohl představovat. Nejlevnější kolize SHA-1 je dnes za cca $100,000 (nebo ještě mnohen levnější, pokud zkusíte znovupoužít známou kolizi). Za kolik zvládnete kolizi SHA1+MD5? Nejlevnější mi známý způsob odhaduju řádově na $10,000,000, a je nad ním spousta otazníků a limitací. Třeba nejasná míra paralelizovatelnosti.
Že si nemohu být jist, že není levnější způsob, který by to zvládnul za malou chvíli? To je pravda. Ale jistotu nemám ani u SHA-2/SHA-3.
> zvýší se jenom iluze bezpečnosti, což je vždy nebezpečné – protože se dotyčný nejspíš nechá ukolébat tím, že pro bezpečnost něco udělal, místo aby rovnou řešil přechod na SHA-2.
Souhlas. Pokud to jde, je přechod na SHA-2 lepší z hlediska bezpečnosti a možná i z hlediska výkonu. Vzácně se ale mohou objevit komplikace, které SHA1+MD5 může řešit – třeba absence HW akcelerace u embedded zařízení. Pak je to na zvážení rizik.
Rozdíl je v tom, že SHA-2 a SHA-3 byly navržené s tím, aby odolaly útoku, a bylo to různými způsoby ověřováno. V případě kombinace SHA1+MD5 to tak navržené nebylo a pravděpodobně to nikdo neověřoval. Osobně vnímám velký rozdíl mezi „zkoušeli jsme to rozbít a nešlo to“ a „zatím to nikdo rozbít nezkusil a doufáme, že to bude obtížné“. Proto jsem to přirovnával k home-made šifrám, pro které je typické to druhé tvrzení. A často opravdu mohou reálně „fungovat“, protože se nikomu nevyplatí je rozbíjet. Ale je to sázka do loterie, já dávám přednost těm algoritmům, které se největší experti pokoušeli rozbít a víme, jak dopadli.
Ne, kombinace MD5 a SHA-1 je špatný nápad. Výsledek zabere o cca 1 hodinu déle, než louskání samotné SHA-1. Respektive před deseti lety.
https://www.root.cz/clanky/tunely-v-hasovacich-funkcich-kolize-md5-do-minuty/nazory/84760/
Člověk by čekal, že je to "stará známá věc". Ale asi si prostě noví lidé musí zopakovat staré chyby.
Hledání kolize SHA-1 trvá přibližně rok. Hledání kolize MD5 trvá na obdobném hardwaru mnohem méně než sekundu. Myslíte si, že když chcete zlomit obě, stačí ty časy prostě sečíst?
Já myslím, že musíte navrhnout nový algoritmus hledání kolize SHA-1, který z hledání předem vyloučí takové možnosti, které zároveň nejsou MD5 kolizí. Netroufám si odhadovat, o kolik bude takový algoritmus náročnější. Je dost dobře možné, že vůbec, ale může taky platit, že nesmírně.
To, co odkazoval, je skutečně validní útok. A čas je vyšší než součtový. Tehdy šlo najít kolizi MD5 pod minutu, takže proč přičítat celou hodinu k celkovému času?
Ale, jak jsem psal, útok předpokládá, že se ve druhé fázi na jednu z funkcí provede bruteforce. Těžko ve druhé fázi něco optimalizovat, byť vyloučené to samozřejmě není.
Tuto „starou známou věc“ jsem zde i zmiňoval, byť jsem na to navrhoval jít naopak. Ale pozor na podstatné detaily:
Ten příspěvek předpokládá, že SHA-1 lámete hrubou silou. Pak zmíněné skutečně platí – vygenerujete multikolizi MD5 a během „hodiny“ máte 2^80 hodnot se stejným MD5 hashem, které „jen“ musíte projít hrubou silou a najít tam (AFAIK s pravděpodobností 1/2) kolizi SHA-1. No, good luck s 2^80… A vysledná dvojkolize bude mít 160 bloků, tj. 10KiB.
Vy nejspíš predpokládáte, že tu kolizi SHA-1 uděláte pomocí algoritmu, který Google plánuje zveřejnit, a tedy se složitostí od oka pár řádů pod 2^64. No, to teď z fleku nevyvrátím, ale dost o tom pochybuju. Ten algoritmus našel kolizi na dvou po sobě jdoucích blocích, které mohl libovolně volit. Tady ji má najít na 160 blocích, kde ale může volit jen ze dvou variant, a to ještě musí volit po dvou po sobě jdoucích blocích. Jinak řečeno, algoritmus má osmdesátkrát po sobě na výběr ze dvou variant pro následucících 128B. To je dost omezující podmínka, a tuším, že ten algoritmus takto nepůjde použít.
Proto jsem ostatně navrhoval vyrobit multikolize na SHA-1 a teprve MD5 mlátit hrubou silou. Ani tady si nejsem jist, jestli mi to preconditions k útoku dovolí, ale zřejmě je to časově i prostorově úspornější varianta. (Což před deseti lety asi úplně neplatilo, tehdy se moc nevědělo, jak SHA-1 lámat rychleji než hrubou silou.)
K té odpovědi Linuse, Linus tam zapomněl (nebo to v té době Git ještě neuměl?), že SHA-1 se používá i pro podepisování, takže můžu ověřit, že všechny soubory v určitém commitu v nedůvěryhodném vzdáleném repozitáři jsou původně opravdu z Linusova repozitáře. Nicméně současné kolize jsou stále dost vzdálené zneužitelnosti u textových souborů.
"Google společně s CWI představil útok SHAttered, kterým je možné tento čas zkrátit sto tisíckrát. Na stovce grafických procesorů tak dokážete vytvořit kolizní dokumenty během jednoho roku."
Rabin rozjima s Bohem. "Pane Boze, Ty jsi tak velky, mocny, dohlednes do vsech koutu vesmiru, ... co je pro Tebe chvilicka?"
"10 000 let", odpovi Buh.
"A co je pro Tebe trosicka penez?"
"100 000 000 000 korun."
"O, velky Pane, vis prece jak na tom jsem a co vsechno bych mohl udelat pro nasi komunitu, ale starost o materialni zavazky me zdrzuje od dulezitejsich veci. Mohl bys mi, prosim, podarovat trosicku penez?"
"Ale jiste, beze vseho, jen prave ted mam take neco na praci, musis chvilicku pockat."
Chudák pražský dopravní podnik. Nejsilnější nabízená šifra (3DES_EDE_CBC_SHA) na jejich eshopu[1] má prolomený hash...
Ale o problému vědí, jen si musí udělat čas na plánovaný upgrade Windows Server 2003.
[1] https://www.ssllabs.com/ssltest/analyze.html?d=eshop.dpp.cz
Linuxová reakce: http://marc.info/?l=git&m=148787047422954
A diskuse k ní: https://news.ycombinator.com/item?id=13719368
tldr: Linus spíš spekuluje a na útok se pořádně nepodíval.
myslím, že to vážně bere, ale na útok se i tak očividně nepodíval :).
Už vznikají první experimenty na přidání kontroly do gitu https://github.com/peff/git/commit/73c56102c8d95d0617ddc8db18ab87c5b019261c
Hlavní riziko nevidí v kompromitaci kernel.org, který je dobře hlídaný, ale repositářů s binárními bloby, těch je i tak spusta.
Zajímalo by mne, jak to s použitím SHA-1 jako unikátních identifikátorů bude. Protože Git a Mercurial nejsou jediné systémy, kde se takhle SHA-1 používá, používá to třeba NoSQL databáze Modeshape a nejspíš i další. V případě Gitu a Mercurialu to nemá žádnou bezpečnostní funkci, v případě NoSQL databází už by to v některých případech mohl být vektor útoku – ale jde mi o ty případy, kdy to není bezpečnostně relevantní.
Dává smysl v takových případech používat SHA-1 pořád dál? Nebo bychom si měli zvyknout dělat i tyhle identifikační funkce formou pluginů, aby bylo možné je průběžně měnit? Pak je také otázka, kdy to ještě není bezpečnostně relevantní a kdy už je. U NoSQL databází si lze snadno představit způsob použití databáze, kdy toho někdo bude moci zneužít. Asi by se dal vymyslet i takový případ použití Gitu nebo Mercurialu – mají na to ty systémy brát ohled?
Jinak podle mne to v současné době problém pro Git ani Mercurial není, protože v obou případech se SHA-1 používá jen jako identifikátor objektů. Pokud by někdo schválně vygeneroval kolizní objekt, vznikne tím problém jenom v tom, že zmate příslušný systém. To je ale podobný problém, jako když někdo pushne změněnou historii nebo koneckonců když commitne špatný kód. Opatření proti tomu je ve všech případech stejné – kontrolovat, kdo a co může pushovat do oficiálních repository.
SHA-1 jako unikátních identifikátorů
Podle mě je problém už jen v tomto. Hash fce z principu žádným unikátním identifikátorem není, protože čistě jen z principu fce existuje nekonečně mnoho kolizí. Hash fce jsou velmi dobrý první indikátor jedinečnosti dat, ale rozhodně je stále nutné porovnat data samotná, zda náhodou nejsou různá.
Mnoho systémů jen spoléhá na to, že pokud se rovnají hash fce, rovnají se i data. Jenže tato implikace v obecném případě vůbec neplatí.
Pokud by někdo schválně vygeneroval kolizní objekt, vznikne tím problém jenom v tom, že zmate příslušný systém.
No jenže to je velký problém, protože ty systémy člověk používá na ukládání obecných dat a uživatel by vůbec neměl řešit, že se tomu nějaká konkrétní data nelíbí.
Nevím, jak je to u gitu, ale někdo na abclinuxu postoval co se stane, když se ty kolizní soubory vloží do subversion. svnku se to evidentně vůbec nelíbí.
http://www.abclinuxu.cz/zpravicky/generovani-kolizi-sha-1/diskuse#22
Opatření proti tomu je ve všech případech stejné – kontrolovat, kdo a co může pushovat do oficiálních repository.
Dobře, takže když jsem cryptolog, tak do gitu nesmím pushovat kolize? Není to trochu nesmysl? Nebo bych měl dokonce kontrolovat obsah těch obecných souborů (já naprosto normálně používám git pro obecná binární data) - není náhodou přesně tohle práce těchto systémů?
Když to budete brát takhle, jediným skutečně unikátním identifikátorem jsou ta data samotná. A nebo pak musíte mít mapovací tabulku mezi identifikátorem a daty, což má ještě větší režii. Hashování se používá v případě, kdy potřebujete zmenšit objem dat i za cenu velmi malé pravděpodobnosti, že dojde ke kolizi. Když to stačí pro elektronické podepisování nebo bankovní operace, proč by to nestačilo pro uložení nějakých zdrojáků.
Ta implikace samozřejmě neplatí, ale ona se také nikde nepředpokládá – vždy to je „je dostatečně pravděpodobné, že se rovnají i data“. Na tom není nic špatného – třeba u rsyncu je nepatrná pravděpodobnost, že po přenosu nebudou soubory na obou stranách shodné, i když budou všechny kontrolní součty sedět. Ale ta pravděpodobnost je mnohem menší, než že se ta data poškodí už na zdrojové straně, takže to prostě riskujeme.
Podle toho, co píše Linus, nepoužívá Git přímo hash jednotlivých souborů. Takže nejde o to, že by se tomu konkrétní reálná data nelíbila. Někdo by musel udělat speciální commit s úmyslem vytvořit kolizi. A Git prostě není systém na ukládání libovolných dat, omezuje se na reálná data. Když se pokusíte commitnout do Gitu exabajtový soubor, taky s tím bude problém. Pokud nějaký verzovací systém používá jako identifikátor přímo hash souboru, je to problém, protože uložení kolizních souborů do VCS je reálný způsob použití.
Obsah obecných souborů kontrolovat nemusíte, protože u nich je právě extrémně malá pravděpodobnost, že dojde ke kolizi.
Když to budete brát takhle, jediným skutečně unikátním identifikátorem jsou ta data samotná.
Ano.
A nebo pak musíte mít mapovací tabulku mezi identifikátorem a daty
Ano, co je na tom divného?
Když se pokusíte commitnout do Gitu exabajtový soubor, taky s tím bude problém.
Pokud ten systém bude tvrdit, že zvládá exabajtové soubory, tak po uložení exabajtového souboru budu očekávat, že vše funguje. Tolik tedy ke zjevnému rýpnutí ;-).
Tohle jsem ostatně kritizoval už před mnoha lety, kdy jeden db systém na stránce s limity tvrdil, že limit na velikost db je 2TB a vedle toho byl veselý smajlík, že to netestovali. Ok, dík za informaci, že to nemám používat a že se tomuto systému mám na hony vyhnout (otestovat v té době 2TB dat bylo zcela reálné, a poctivé by bylo přiznat, že teoretický limit je 2TB, ale reálně to testovali třeba jen na 100GB, to bych ještě bral).
Divného je na tom to, že pak nepotřebujete žádné identifikátory, prostě budete všude přenášet jen kompletní data. A i ta data budete přenášet donekonečna, protože spolehlivost přenosu po síti (ale ostatně i z disku nebo z paměti) je chráněná zase jen kontrolními součty.
Netuším, jak byste si to v praxi představoval. Dobře, rsync nebudete používat, protože používá pro zjištění shody dat jen kontrolní součty. Budete tedy přenášet po síti celý soubor. Jenže spolehlivost toho přenosu je na úrovni TCP/IP chráněna zase jen kontrolními součty. Takže když soubor přenesete a budete chtít ověřit, že jste ho přenesl správně, budete ho muset přenést ještě jednou a ty dvě kopie pak porovnat. Jenže nulová není ani pravděpodobnost, že se ten soubor přenese dvakrát se stejnou chybou. To ten jeden soubor budete přenášet donekonečna? Nebo se smíříte s tím, že spolehlivost není 100 % a že prostě existuje nenulová pravděpodobnost, že se to přenese špatně? A když se smíříte s tou nenulovou pravděpodobností, co je špatného zrovna na té pravděpodobnosti, že dojde ke kolizi SHA-1 u dvou reálných souborů?
Mě se líbí, jak vše ženeš ad absurdum.
Je potřeba si uvědomit, že nelze vyřešit všechno. Jenže to současně neznamená, že na místech, kde to řešit lze, se na to řešení vyprdnu. A to je to, co mi na těchto diskusích vadí asi nejvíc. Tedy, když ty soubory mám nebo můžu mít, tak je rovnou porovnám byte po byte. Tam, kde to nejde, tak to prostě nejde a musím spoléhat na nějakou dobrou fci.
Takže tam, kde lze porovnávat celá data, by se měla porovnávat celá data. Ano, všichni víme, že na disku a ram se používají ecc, dokonce se u některých médií rovnou používá samoopravný kód, protože jinak by to nefungovalo vůbec. Ale to přece není důvod pro odstranění další možné kontroly Naopak mě to teda přijde jako důvod pro to dělat další kontroly, takže třeba moderní fs mají vlastní kontrolní součty - i když je má i disk, a některé db mají ještě další kontrolní součty - takže tam ve výsledky mohou být kontroly 3 - disk, fs, db + ještě ecc v ram a cpu.
A když se smíříte s tou nenulovou pravděpodobností, co je špatného zrovna na té pravděpodobnosti, že dojde ke kolizi SHA-1 u dvou reálných souborů?
No především bych chtěl říct, že já se se sha-1 nesmířím v ničem už od roku 2010. Takže řešit toto téma v roce 2017 je pro mě trochu zastaralé, pro mě už zkrátka neexistuje. A o tom bychom se asi měli bavit v první řadě, pro mě zkrátka funkce, u kterých kryptologové naleznou nějaké oslabení, prostě končí. Ano, můžeme se bavit o tom, co teda používat, když i rodina SHA-2 je lehce nalomená, na to odpovídám, že používám sha-512 a velmi intenzivě se dívám po nástupci (jestli to bude sha-3 nebo něco jiného zatím nevím).
Ad absurdum to ženu, protože ty jsi žádnou hranici neuvedl a psal jsi to právě takhle obecně – použití hashe jako identifikátoru je vždy špatně.
když ty soubory mám nebo můžu mít, tak je rovnou porovnám byte po byte
Takže rsync nepoužíváš? Tam soubor máš nebo můžeš mít. Píšeš o kontrolních součtech na úrovni souborového systému – to je ale podle téhle věty také špatně. Tam přece soubor také mám, takže bych neměl pro kontrolu zapisovat jeho kontrolní součet, ale rovnou celý soubor.
Ano, zase jsem to dovedl ad absurdum. Protože ty napíšeš nějaké pravidlo, které by se podle tebe mělo samozřejmě dodržovat – to absurdní je pak ale jenom příklad postupu podle toho pravidla.
já se se sha-1 nesmířím v ničem už od roku 2010
Já jsem z tvrdého použití SHA-1 v Gitu měl špatný pocit už v roce 2005, právě z toho důvodu, že jednou muselo dojít k tomu, že bude SHA-1 pro kryptografii nedostatečné. Ale je to pořád jen ten pocit, že není dobré používat něco, co je označené za zastaralé. Na druhou stranu nevidím pořád problém v tom využívat hash jako identifikátor. Někde se používá i UUID, to má ještě mnohem méně entropie.
pro mě zkrátka funkce, u kterých kryptologové naleznou nějaké oslabení, prostě končí
Pro kryptografické použití jistě. Ale má končit i jako generátor unikátních identifikátorů? Proč?
použití hashe jako identifikátoru je vždy špatně
Je to špatně všude tam, kde je možné používat původní data jak identifikátor. Samozřejmě, teď se můžeme dohadovat o tom, co to přesně znamená "je možné" a kde je ta hranice. To by ale měl vycítit návrhář toho kterého systému.
Takže rsync nepoužíváš? Tam soubor máš nebo můžeš mít.
Ano a rsync má taky mód, kdy se vykašle na nějaké porovnání a rovnou ta data zkopíruje.
Já jsem z tvrdého použití SHA-1 v Gitu měl špatný pocit už v roce 2005
No tak to každopádně. On byl taky Linus docela kritizován a už tehdy reagoval na možné výtky. Na druhou stranu (jak psal O. S. Nekola) je git evidentně dost odolný i proti hodně stupidní fci.
Na druhou stranu nevidím pořád problém v tom využívat hash jako identifikátor. Někde se používá i UUID, to má ještě mnohem méně entropie.
No jenže tím použitím UUID zase může dát vývojář najevo, že tady opravdu nepotřebuje nějakou kryptograficky silnou funkci a že je to opravdu jen identifikátor. Já jsem zastánce silného typování, takže datový typ uuid je mému srdci mnohem bližší, než něco jiného a to, že to má jen 128b (a to ještě pouze v jedné z těch pěti verzí) mi nijak nevadí (v některých případech může být dokonce výhodné použít ty verze s časem).
git interně soubory pojmenovává přes sha1, kromě hashe obashu k tomu jde ale i třeba filesize. Je tady teoretická možnost podstrčit jiný commit pro PR než ten který byl schválený, kluci od gitu pracují na změně hash funkce (teoretická příprava) a nejspíš přidají ochranu pro tenhle typ útoku, viz odkazovaný commit.
Uložení do gitu těhle dvou pdf, git nezboří a ani si toho nevšimne.
Předpoklad tohoto útoku je, že mám v podepisovaných datech možnost měnit pár bajtů aniž bych poškodil daný soubor. PDF je k tomu ideální, dokáže vesele ignorovat mnoho dat. U gitu není možnost, jak do commitu vložit binární data, aby je nikdo neviděl. Pokud bych tam chtěl mít sekvence jen určitých bitů (ascii, bez \0 atd.), exponenciálně tím zvyšuji složitost. Nebo bych potřeboval commitnout binární soubor, což opět není tak moc běžné.
git interně soubory pojmenovává přes sha1, kromě hashe obashu k tomu jde ale i třeba filesize
Což zrovna v tomto případě příliš nepomůže:
$ ls -lb -rw-r--r-- 1 tomas tomas 422435 Feb 25 11:58 shattered-1.pdf -rw-r--r-- 1 tomas tomas 422435 Feb 25 11:58 shattered-2.pdf $ sha1sum * 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-1.pdf 38762cf7f55934b34d179ae6a4c80cadccbb7f0a shattered-2.pdf
Ale git drží, zkoušel jsem vše co mě napadlo a nepodařilo se mi to rozbít (clone, push, gc, repack, reset).
Ta ochrana v Gitu je proti náhodným kolizím, tam je nepravděpodobné (přesněji: ještě o několik řádů méně pravděpodobné, než že vůbec nastanou), že by měly stejnou délku souboru. Proti útoku to nechrání, to ani nebylo účelem, proti útoku se spoléhá to na to, že útočník stejně nemůže přepsat existující objekty. Je teď trochu problém s podpisy, ale to se asi vyřeší tak, že podpisy nebudou podepisovat jen commit, ale i jeho obsah.
nejspíš přidají ochranu pro tenhle typ útoku
Mně ale právě není jasné co je ten „tenhle typ útoku. Že útočník naklonuje repository, vymění v něm jeden commit za škodlivý kód tak, aby seděl hash, a repository někde vystaví na internetu? V čem se tenhle útok liší od útoku, kdy útočník vymění commit, ale hash sedět nebude? On někdy někdo porovnává autenticitu repository tak, že porovnává hashe commitů? Nebo je to útok, který by někdo mohl zaútočit přímo na Linusovo repository? Útočník pošle commit, ostatní ho prohlédnou, schválí, Linus ho začlení, útočník pak vytvoří jiný commit se stejným hashem – a bude s ním dělat co?
tohle co představil google je šíleně závislé na vyměňování konkrétních bitových slov, pro které sha1 má určitou slabinu. Existuje snadný způsob jak zjistit, jestli daný dokument obsahuje tyhle podezřelé sekvence https://github.com/cr-marcstevens/sha1collisiondetection
Útok na git nebyl ještě proveden a o jeho vektoru můžeme tedy jen spekulovat. Je třeba možné udělat PR, nechat si ho zkontrolovat a na svůj server poté vystavit repo s vyměněnými soubory a doufat, že jejich integrační server si to stáhne. Je v tom poměrně dost sociálního inženýrství a je to snadno odhalitelné, jsou snadnější a levnějšího útoky.
Ano, je běžné, že třeba každou noc se nad všemi repositáři spouští git fsck, který tuhle kontrolu provede. V systémech, které mám pod palcem to je samozřejmost, dělá se to třeba i u kernel.org. Pokud v historii gitu vyměníš jeden commit, nebude sedět celý tree a nepůjde z takové repository jednoduše mergetovat.
Mně právě není jasné, jak by se do nějakého repozitáře dostal ten podvržený commit se stejným hashem, a zároveň aby se tam nemohl dostat špatný commit s jiným hashem. Podle mne repozitář musí být před špatnými commity chráněn nějak obecně, a nedovedu si představit, že by ta ochrana byla závislá na hashi commitu.
Git identifikuje pomoci sha1 i soubory. Takze si predstavte teoreticky utok (pokud by byl identifikator jen ten sha1): Dejme tomu, ze vim, ze se chysta nekdo poslat do upstreamu pull-request s <goodfile> identifikovanym pomoci nejakeho sha1. Kdyz budu dost rychly, dostanu pred tim do upstreamu nesouvisejici zmenu, ktera ma nejde v /test-data/ i <badfile>, ktery ma stejny sha1. Myslim, ze by se pak mohlo stat, ze pri fetchi toho pull-requestu se <goodfile> nestahne, protoze preci uz soubor <sha1> uz git ma. Misto nej se pak dosadi <badfile>. A skoro vsichni (krome autora pull-requestu) budou mit bad-file.
pouze záměna souboru právě neprojde, max. tak při commitu, ale poté budou mít rozdílný commit hash a to tady jde, udělat pozměněný commit, ale se stejným commit hashem, kterým jíž byl schválen ale ještě nebyl stažen. Soubory uvnitř gitu jsou ukládány po deltách a konstruují se dohromady až při checkoutu, každá delta má svůj podpis.
Bezpečnost git repositářů nestojí pouze na sha1, ale na celé infrastruktuře, na tom, že každý repositář je celá kopie, na tom, že vše vidí několik očí a důležité projekty mají integrační servery, těch překážek je příliš.
V současné době neexistuje způsob jak rozbít git repositář, nejsme ani schopní dát dohromady teoreticky takový útok (vycházím i z mailing listu git vývojářů).
Kdyz budu dost rychly, dostanu pred tim do upstreamu nesouvisejici zmenu, ktera ma nejde v /test-data/ i <badfile>, ktery ma stejny sha1.
Přičemž to je ale úplně stejný problém, jako když do upstreamu dostanu nesouvisející změnu, která má někde v /test/data i <badfile>, a na hashi přitom vůbec nezáleží. Já pořád vidím problém už v tom, že někdo s úmyslem škodit dostane něco do oficiálního repozitáře. Nebo jinak – na tom, že je v oficiálním repozitáři soubor nebo commit od člověka, který chce škodit, mne vůbec neuklidňuje, že ten soubor nebo commit má unikátní hash.
o to tady právě jde, ten člověk je buď záškodník a tímhle krokem se odepsal nebo to je obeť a má kompromitovaný třeba svůj github repositář. Opět se tenhle krok velice rychle odhalí a git není jen o hashích, ale právě o té několikanásobné lidské a systémové kontrole, projít přes technické zábrany je jedna věc, ale projít do upstreamu je druhá, ještě obtížnější.
Git je proti změnám data ve svých strukturách dost odolný a jednoduše nedovolí cokoliv změnit, už jen kvůli tomu, že nepoužívá prosté hashe obsahu, ale přidává k tomu metadata a ukládá delty u existujících souborů.
Úpravou zdrojáků si lze jednoduše zkusit, jak se git zachová v takovýhle případech. Na commmitnutí těhle dvou "shodných" pdf jde vidět, že ho to nerozbije.
Řešením je podle mě integrovat do gitu ještě PGP, ať je to součást metadat a nemusí se tím prasit commit message, a ano, to je další obrovská bariéra, kterou nelze tak snadno překonat.
Jenže v /test/ může být ten soubor jako ukázka dat, proti kterému mají běžet automatické testy, dokonce to může být ukázka toho, že se parser vyrovná s určitým typem chyby. Zatímco <goodfile> v /src/ může být zdroják se stejným sha1, a jako zdroják bude mít ten soubor úplně jiný význam, než v adresáři /test_data/.
Pouze jsem uváděl hypotetický útok, pokud by byly splněny dva předpoklady, které myslím splněné nejsou:
1. git identifikuje soubory pouze sha1 - to tu již jiní vyvrátili
2. lze vyrobit soubor s kolizní sha1 k souboru, na který chceme zaútočit, bez toho abychom originál modifikovali.
Bodem 1 jsem si v době psaní nebyl jist. Bod 2 padne někdy v budoucnu. Chtěl jsem jen ukázat, že vhodně zvoleným útokem může být podstrčení pouze jediného souboru, a to ještě maskovaného za testovací data. Soubor s testovacími daty je možné protlačit vhodným technicko-sociálním inženýrstvím. Představuji si to tak, že najdu chybu v originálním software, připravím <badfile> tak aby udělal to co chci a zárovreň aby demonstroval chybu. Submitnu ho jako testcase té chyby, pokud možno i s patchem, takže upstream by měl práci navíc s oddělováním testcase od opravy chyby.
V případě celých commitů je situace složitější. Ale nejsem přesvědčen o tom, že je nereálná.
Ano, a já uvádím, že se to tam může dostat snadno, protože těžko bude někdo kontrolovat zda soubor označený test-input-456.cfg, není náhodou kromě příkladu, testujícího, že bug 456 a 478 při čtení konfigurace opraveny, náhodou i platný soubor default.cfg, ve kterém je chyba typu:
#define SECLEVELS 10
security=SECLEVEL
(tedy záměrné typo nastavující security na prázný řetězec), který jen čeká na záměnu s původním /etc/foo/default.cfg.
Může se to tam dostat snadno, pokud může útočník snadno dostat své soubory do oficiálního repository. Což je podle mne ten hlavní problém. Pokud je dotyčný přispěvatelem projektu, může napáchat spoustu škod aniž by si hrál s nějakými kolizemi hashů. A pokud je to náhodný přispěvatel, opět měl by ten jeho příspěvek někdo vzít, projít ho, pochopit a případně upravit a pak se pod něj podepsat. Pokud někdo převezme testovací data, aniž by se podíval, jestli skutečně testují to, co má být opraveno, je to, jako kdyby tam ten test vůbec neměl.
Něco podobného je soutěž v tom jak udělat kód, ve kterém je záměrná chyba, tak aby prošel skrz code review:
http://www.underhanded-c.org/, je to docela zajímavé počtení, především pro céčkaře.
MD5 má 32 znakov od 0-F to jest počet kombinácií 2 na 128 sa rovná 340 282 366 920 938 000 000 000 000 000 000 000 000.
16 znakov 0 1 2 3 4 5 6 7 8 9 A B C D E F
dĺžka MD5 32 znakov
=power(16;32)
Takýto počet výsledných kombinácií stačí pre súbor veľkosti 16Bajtov!
16 Bajtov 128 bitov =power(2;128)
- pokiaľ budeme kombinovať 0 a 1 v súbore o veľkosti 16B tak vyčerpáme MD5-ku a to ešte nerátame kombinácie u súborov dĺžky 15B, 14B, 13B, 12B, 11B atď až po 1BAJT.
Kolízia: 2004
SHA-1 má 40 znakov 0 až F
=power(16;40)
Takýto počet výsledných kombinácií stačí pre súbor veľkosti 20Bajtov!
20 Bajtov 160 bitov =power(2;160)
Kolízia: 2016
SHA-256 má 64 znakov 0 až F
=power(16;64)
Takýto počet výsledných kombinácií stačí pre súbor veľkosti 32Bajov!
32 Bajtov 256 bitov =power(2;256)
SHA-512 má 128 znakov 0 až F
=power(16;128)
Takýto počet výsledných kombinácií stačí pre súbor veľkosti 64Bajtov!
64 bajtov 512 bitov =power(2;512)
Existuje nejaký exe súbor o malej veľkosti napríklad ransomwar do 50kB.
Stačí meniť z 51 200 Bajtov iba 64 Bajtov a vieme napodobniť SHA-512 ľubovoľného súboru čisto teoreticky.
128 bitové MD5 - kolízia 2004
160 bitové SHA-1 - kolízia 2016
Rozdiel: 32 bit - trvá 12 rokov
Rozdiel medzi 160 a 256 bit je 96 bit cca 36 rokov ak by tempo výpočtového výkonu bolo také ako od roku 2004 do 2016 - lenže vývoj v IT nie je lineárny - nemôžeme aplikovať tú istú krivku vývoja - pretože vývoj je exponenciálny presne tak exponenciálny ako je zložitosť 160bitovej SHA-1 a 256bitovej SHA-256.. Snowden Thundra od NSA ????
MD5, SHA-1, ani SHA-2 nemají žádný počet znaků 0–F. MD5 má 128 bitů, SHA-1 má má 160 bitů, SHA-2244 má 224 bitů (všímejte si té shody počtu bitů a názvu), SHA-256 má 256 bitů, SHA-384 má 384 bitů, SHA-512 má 512 bitů. Ty prostocviky s hexadecimálními čísly jste předváděl úplně zbytečně, protože jste se akorát pracně dopracoval od podivného odvození k definici.
A ano, po n-bitový hash platí, že když vypočítáte příslušný hash po všechny možné n-bitové soubory a následně ještě jeden hash pro libovolný jiný soubor, mezi všemi vypočítanými hashi bude alespoň jedna kolize. To je princip hashování, to jste neobjevil nic nového.
Dál už jste se ale od reality odvrátil úplně. Protože praktické nalezení kolizí pro MD5 i SHA-1 právě nezáviselo na délce hashe (na počtu bitů), útok hrubou silou na MD5 i SHA-1 je stále zcela mimo naše možnosti. Útok na obě funkce je vedený tak, že se podařilo najít slabinu v těch funkcích, která umožní jakoby některé možné kombinace při zkoušení rovnou vynechávat. Má to tedy stejný efekt, jako kdyby se ta délka hashe zkrátila. Dokonce se jako ta „zkrácená“ délka hashe odhaduje sílá těch oslabených hashovacích algoritmů, takže MD5 by mělo mít sílu 128 bitů, ale je znám útok, který ho zkracuje na ekvivalent zhruba 18 bitů, což už se na běžném počítači spočítá za méně než sekundu. U SHA-1 bylo oslabení odhadováno někde okolo 60 bitů, ten včera představený útok má 63 bitů.
„Bezpečnost závisí na tom, že není možné najít dva dokumenty se stejným otiskem jinak, než hrubou silou.“
Ne úplně. Jde o to, jestli není možné tyto dva dokumenty najít v použitelném čase, jedno, jestli hrubou silou, nebo jinak. Jinak by mohl být 32b hash bezpečnější než sha1, což exidentně není pravda. Ideální 32b hash možná nepůjde lousknout jinak než hrubou silou, ale hrubá síla bohatě stačí. Naopak modernější hashovací funkce mohou mít teoretické slabiny, které umožní najít kolizi rychleji než hrubou silou, ale to neznamená, že jsou prakticky použitelné.
„Zašifrujete otisk a získáte elektronický podpis konkrétního dokumentu.“
Ehm… zašifrujete? Opravdu? V případě RSA to funguje přesně naopak, podepisuju rozšifrováním hashe.
Proč si to sám nepřečtete aspoň na Wikipedii? Při podepisování se podepisují hashe, protože šifrování/dešifrování asymetricou šifrou je pomalé a šifrovat/dešifrovat jím původní zprávu by bylo zdlouhavé. Ze stejného důvodu se při šifrování zpráva šifruje symetrickou šifrou a asymetrickou šifrou se zašifruje pouze klíč, který se k zprávě přiloží.
Ty vole, Jirsák, o čem to blábolíte? Kde tvrdím, že se šifruje celá zpráva? Já jen říkám, že RSA je možné použít oba klíče jak pro šifrování, tak pro podpis a to jako reakci na výrok mistra šestáka, že "V případě RSA to funguje přesně naopak, podepisuju rozšifrováním hashe.".
To je samozřejmě blbost, protože hash se podepisuje zašifrováním privátním klíčem.
Ale matematicky vzato podpis pomocí RSA opravdu odpovídá dešifrování (až na padding). A ověření naopak odpovídá zašifrování (opět až na padding) a porovnání výsledku s hashem dat.
Ano, je to trošku kontraintuitivní, ale dává to smysl. Místo šifrování a dešifrování mluvme o transformaci a zpětné transformaci. Veřejný klíč dovolí komukoli provést transformaci, zatímco soukromý dovolí svému vlastníkovi provést zpětnou transformaci. Podstatné je, že zatímco transformaci může provést kdokoli, zpětnou transformaci může provést jen vlastník soukromého klíče. A nyní tento systém transformací můžeme využít:
a. Na šifrování, kdy transformace bude fungovat jako šifrování a zpětná transformace jako dešifrování.
b. Na podpisy, kdy zpětná transformace bude sloužit na podepsání a transformace bude sloužit na ověření.
Pokud přehodíte transformaci a zpětnou transformaci, ztratíte bezpečnost, protože najednou mohou podepisovat nebo dešifrovat všichni. A tady snad je jasné, v čem odpovídá RSA podepisování a RSA dešifrování. A ono to neodpovídá jen tím, že k tomu potřebuju privátní klíč, ona to je do jisté míry totožná operace. Rozdíl je jen v tom, že u podepisování vstup zahashuju, zatímco u šifrování doplním padding. Pak se ale postupuje stejně.
Sémanticky samozřejmě podepisování není šifrování ani dešifrování.
Při šifrování a dešifrování platí, že dešifrování musí být inverzní operace k šifrování. Od šifrování také obvykle chceme, aby výstup byl (až na případné zarovnání) stejně dlouhý, jako vstup, aby tedy jakákoli náhodná data byla potenciálním výstupem šifrování. Z toho plyne, že i šifrování musí být inverzní operací k dešifrování. U asymetrických šifer tedy platí, že když na vstupu provedete transformaci s pomocí privátního i veřejného klíče, přičemž nezáleží na pořadí (protože obě transformace jsou navzájem inverzní), dostanete opět vstup.
Vy za šifrování označujete vždy transformaci veřejným klíčem a za dešifrování vždy transformaci soukromým klíčem (proto vám pak podepisování vychází jako dešifrování). Obvyklejší je myslím označovat to podle pořadí operací, tj. první operaci označovat za šifrování a druhou za dešifrování. Už pro to, že tohle označení bude fungovat i pro případy, kdy šifrování nepokryje celý možný obor hodnot – kdybyste v takovém případě začínal dešifrováním, může se vám stát, že narazíte na vstup, kro který není dešifrování definováno. Třeba kdybyste šifrování definoval jako zdvojení každého písmena a dešifrování jako sloučení dvou stejných písmen na liché a následující sudé pozici (takže„A“ by se zašifrovalo jako „AA“), není pro vstup „AB“ dešifrování definováno.
Chápu vaši nechuť označovat za výsledek šifrování něco, co je veřejné, nicméně u podpisu jsou veřejné oba texty – jak vstupní text, tak výsledek transformace.
Bezpečnost je daná tím, že soukromý klíč nikdy nesmí být zveřejněn, teprve z toho je odvozené, kterou transformaci kdo může použít a z toho plyne pořadí těch transformací.
Šifrování a ověření podpisu hashe jsou matematicky vždy totožné operace, stejně jako dešifrování a vytvoření podpisu z hashe. To vyplňování při šifrování není striktně vzato součástí šifrování, je to příprava vstupu pro šifrování. A hashování vstupního dokumentu není součástí podepisování, podepisuje se vždy hash dokumentu, a podepisující někdy ani vstupní dokument nezná, zná jenom hash – např. při vystavování časových razítek (což, pravda, není jen podpis hashe, ale podpis hashe plus časové značky).
Šífrování je u mě operace, která útočníkovi prakticky nedovolí dostat se k původnímu obsahu. To bývá i účel šifrování. Naopak dešifrování je operace, kterou může provést pouze vyvolený, což rozhodně není vlastník veřejného klíče.
Přeneseně tak můzeme nazývat operace, které sice slouží k něčemu jinému (zde podpisy a jejich ověřování), ale matematicky tomu odpovídají.
> Vy za šifrování označujete vždy transformaci veřejným klíčem a za dešifrování vždy transformaci soukromým klíčem (proto vám pak podepisování vychází jako dešifrování).
Ve výsledku ano, z důvodu, který jsem uvedl výše.
> Obvyklejší je myslím označovat to podle pořadí operací, tj. první operaci označovat za šifrování a druhou za dešifrování.
Jenže pak to neodpovídá ani sémanticky (to ani u mě – podpis nemá sémanticky nic společného se (de)šifrováním) ani matematicky. Je to prostě operace prováděná jako první a operace prováděná jako druhá. Podobnou zkratku, jakou jsem tu kritizoval na Rootu, bych pochopil třeba na iDnes, kde je jiná skupina čtenářů i redaktorů.
> tohle označení bude fungovat i pro případy, kdy šifrování nepokryje celý možný obor hodnot
To vím. Však jsem úmyslně zmiňoval RSA, kde se to takto používá, a nepsal to obecně.
> Bezpečnost je daná tím, že soukromý klíč nikdy nesmí být zveřejněn, teprve z toho je odvozené, kterou transformaci kdo může použít a z toho plyne pořadí těch transformací.
Ano. Ale nemohu si vždy libovolně vybrat, který klíč bude soukromý a který veřejný. Odvodit veřejný klíč ze soukromého jít může, naopak ne. Provádět oba směry transformace soukromým klíčem jít může, veřejným ne.
> To vyplňování při šifrování není striktně vzato součástí šifrování, je to příprava vstupu pro šifrování. A hashování vstupního dokumentu není součástí podepisování, podepisuje se vždy hash dokumentu, a podepisující někdy ani vstupní dokument nezná, zná jenom hash
Jak se to vezme – záleží, jak moc highlevel/lowlevel pohled chceme. Pokud například chceme mít podepisovací schéma, které není náchylné na malleability, s čistým RSA si nevystačíme. Stejně tak u šifrování. Zmínkou o paddingu jsem chtěl vyhovět i těm, kteří mají více high-level pohled a mohli by namítnout, že to přece není úplně totožná operace – padding/hash tam potřebujeme nejen kvůli délce zprávy, ale i kvůli bezpečnosti, nelze to tedy vynechat. Ostatně tu námitku vznáší i autor článku, který jsem odkázal.
Ale jinak asi je fakt, že RSA by mělo odkazovat na čisté (samostatně nepoužitelné) primitivum RSA, zatímco pro šifrování budeme mluvit o RSA-OAEP, pro podepisování budeme mluvit o RSA-SHA256 apod. Problém je, že se často uvádí pouze RSA (popř. AES), i když jde o jeden z mnoha dílků skládačky.
Pokud šifrování používáte pro operaci, která znemožní útočníkovi dostat se k původnímu obsahu, pak nemůžete pojem „šifrování“ vůbec používat v kontextu elektronického podpisu – protože tam jsou z principu oba dva bloky dat veřejné, jak hash dokumentu tak jeho transformovaná podoba.
Vaše pojmenování transformace soukromým klíčem jako „šifrování“ sice má svou logiku, ale neodpovídá to tomu, jak se ta slova běžně používají. Běžný význam slov je ten, který jsem popsal – první transformace je vždy šifrování, druhá dešifrování. Když se někde píše o elektronickém podpisu a používá se pojem „šifrování“, většinou se píše o tom, že hash dokumentu jeho autor zašifruje privátním klíčem, při ověření podpisu se pak podpis dešifruje klíčem veřejným. I když je pravda, že třeba česká Wikipedie u popisu algoritmu RSA pro podpis píše jakoby „dešifrování“, takže tam je použitá vaše terminologie, ale aspoň je to zdůrazněné tím „jakoby“ a uvozovkami. Ale je to jediný případ, který jsem našel, jinak se v publicistických textech používá pro podpis „šifrování soukromým klíčem“, v odborných textech se to spíš popisuje přímo matematickými operacemi.
Jaké termíny použijete samozřejmě záleží na vás, ale když je bez upozornění použijete opačně, než jak je většinou zvykem, je to matoucí.
> protože tam jsou z principu oba dva bloky dat veřejné, jak hash dokumentu tak jeho transformovaná podoba
Znamená to, že když zašifruju veřejně známý text, a útočník se nějak dozví, že to je zrovna ten text, tak už nejde o šifrování? Ne. Pouze útočník má apriorní znalost a z ciphertextu se nedozvěděl o plaintextu nic, co by nevěděl už předtím. Ano, mohl jsem to tak rozepsat už předtím, ale příspěvek by byl s tímto přístupem dvakrát tak dlouhý: Útočník se z ciphertextu dozví maximálně délku plaintextu a všechno, co lze vyvodit z délky plaintextu v kombinaci s jeho apriorními znalostmi.* Byl by tak ale můj komentář srozumitelnější?
> neodpovídá to tomu, jak se ta slova běžně používají
Co mám považovat za běžné používání? Pokud spíše laickou veřejnost, kde na iDnesu označují SHA-1 za „šifru“ (byť v uvozovkách), tak tam to ještě chápu. Ale něco na základě takového textu pochopit mi pak přijde dost obtížné. Pokud ale jsme na odborném serveru, dá se čekat, že čtenáři takového článku budou vědět, že kryptografie není jen o šifrování. A tedy se budou věci nazývat pravými jmény, tedy místo „Zašifrujete otisk a získáte elektronický podpis konkrétního dokumentu.“ spíše něco jako „Do podepisování typicky vstupuje z praktických důvodů pouze otisk, takže dva dokumenty se stejným otiskem budou mít stejný podpis.“.
Zmínka o tom, že v RSA jde de facto o dešifrování, měla jen ilustrovat, jak je zmínka o šifrování nepřesná.
Co so vzpomínám na předmět Applied cryptography na MU FI, na první přednášce k terminologii bylo „Nešifrujeme soukromým klíčem“. Tehdy jsem si říkal, proč to vlastně zmiňuje.
*) Praktická ukázka: pokud útočník předem ví, že zpráva je buď „ano“, nebo „ne“, může z délky zprávy odvodit i celou původní zprávu.
V případě podepisování to ale není „útočník se nějak dozví“. Podepisování je založené na tom, že ověřovatel podpisu zná hash dokumentu. Takže tam se ta transformace neprovádí pro to, aby se něco skrylo před útočníkem. Ostatně při použití symetrické šifry zastává šifrování obě funkce – jak zabránit útočníkovi dozvědět se text zprávy, tak to zároveň pro příjemce ověřuje autenticitu zprávy, protože nikdo jiný než vlastník klíče nemohl zprávu správně zašifrovat.
V souvislosti s elektronickým podpisem se spojení „zašifrovat hash privátním klíčem“ běžně používá. Je to tedy rozhodně správnější vyjádření, než „rozšifrovat hash privátním klíčem“.
> Takže tam se ta transformace neprovádí pro to, aby se něco skrylo před útočníkem.
Ano, a navíc tento druh transformace to ani není schopen zajistit, proto tomu neříkám šifrování
> Ostatně při použití symetrické šifry zastává šifrování obě funkce – jak zabránit útočníkovi dozvědět se text zprávy, tak to zároveň pro příjemce ověřuje autenticitu zprávy, protože nikdo jiný než vlastník klíče nemohl zprávu správně zašifrovat.
To je (relativně rozšířený) omyl. Ano, útočník bez klíče nemohl zprávu zašifrovat, ale mohl zprávu pozměnit (vizte malleability). Proto se se symetrickými šiframi ještě používá MAC. Pripadně existují AEAD módy, ale to je v podstatě jen skrytý MAC.
> V souvislosti s elektronickým podpisem se spojení „zašifrovat hash privátním klíčem“ běžně používá.
Setkal jsem se s tím poprvé asi včera. A nemám pocit, že bych se kryptografií nezabýval.
> Je to tedy rozhodně správnější vyjádření, než „rozšifrovat hash privátním klíčem“.
Neodpovídá to ani sémantice ani matematické operaci. Nesedí to typově. Narozdíl od rozšifrování hashe.
Pokud nejde o matematické detaily, mluvme o podepisování a ověřování podpisu, ne o šifrování/dešifrování.
A pokud nám jde o tyto detaily, tak podepisování pomocí RSA v podstatě odpovídá dešifrování.
Záleží, co chci říct:
Pokud chci ukázat důvod, proč to provádím, pak je špatně psát o šifrování/dešifrování. Proto dávám přednost se slovům šifrovat/dešifrovat úplně vyhnout v takovém případě.
Pokud chci popsat, čemu to odpovídá matematicky, nevidím v tom problém.
P.S.: původně ta zmínka o dešifrování měla být jen tak na okraj. Hlavní sdělení mělo být, že nejde o šifrování. Možná jsem to měl jinak formulovat…
Já jsem se také doposud setkal s pojmem "šifrování" ve smyslu udělat ze známeho textu text nový, odvozený matematickou operací. Tedy první operace, ať už je dělaná soukromým, nebo veřejným klíčem. Dešifrování je pak získání původního textu, tedy operace druhá v pořadí.
Zmatení vzniká až díky tomu, že k "zašifrování" hashe pro podpis se používá stejná operace jako při "dešifrování" zprávy při normálním šifrování.
Dešifrovat pomocí veřejného klíče – tedy že si to bude moci přečíst kdokoli, kdo zná *veřejný* klíč? K čemu by to pak bylo?
To rozšifrování není 100% přesné, ale když si odmyslíme padding, je to vpodstatě ta stejná operace: https://www.cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_sign_vs_dec.php (Podstatný je obsah, nejen titulek. )
Watershed SHA1 collision just broke the WebKit repository, others may follow:
Nechtel bych ted spravovat svn repa...