Názor k článku
Git 2.13 přidává obranu proti kolizi SHA-1 od Filip Jirsák - Kvůli decentralizaci si moc nedokážu představit, že hash...

  • Článek je starý, nové názory již nelze přidávat.
  • 13. 5. 2017 12:57

    Filip Jirsák
    Stříbrný podporovatel

    Kvůli decentralizaci si moc nedokážu představit, že hash alg. bude určovat správce repa
    Pokud nebude hashovací algoritmus určovat správce repository, není potřeba nic měnit a můžeme zůstat u SHA-1. Vždyť celá ta změna se dělá kvůli tomu, že dnes by mohl nějaký zákeřný přispěvatel vytvořit dva různé commity se stejným hashem. Když necháte volbu hashovací funkce na přispěvateli, zákeřný přispěvatel si zvolí SHA-1 – a jsem tam, co dnes.

    co pak bude dělat s PR? Bude nutit je povinně přecommitovat s jeho hashem?
    On by to ani správce repository dělat nemusel, prostě by si hash přepočítal sám. Ale jinak na tom nevidím nic divného – když někdo dává požadavek na přetažení, musí si zajistit, aby jeho požadavek navazoval na stav repository, do kterého chce commit přetáhnout. Když jsou konflikty v kódu, musí to dělat ručně – naproti tomu přeznačení commitů se udělá automaticky.

    zachovat 160 bitovou velikost hashe
    To je krátkozraké řešení. Délky hashovacích funkcí se postupně prodlužují, protože jak se postupně zvyšuje výpočetní výkon, dokážeme toho víc upočítat hrubou silou, i kdyby ta hashovací funkce jinak byla bezchybná. Takže za nějakou dobu se bude řešit, že 160 bitů je prostě málo entropie, ať je získáte jakkoli. Dá se to brát jako dočasný workaround – na SHA-1 už existuje postup prolomení, tak použijeme jinou hashovací funkci se stejně dlouhým výstupem. Ale trvalé řešení to není. Navíc tohle osekávání hashovacích funkcí je dost ošemetné – ty hashovací funkce na to nikdy nebyly navržené a testované, takže je to další potenciální vektor útoku. Zrovna SHA-2 mají i ořezané varianty, takže snad v tomto směru budou odolné – ale tyhle zásahy kryptologů–amatérů jsou nebezpečné.

    Prozatím sha1 dostačuje
    Záleží na tom, co se od gitovského repository vlastně požaduje. Já si taky myslím, že pokud někdo může v repository napáchat škody commitem s konfliktním hashem, může tam napáchat daleko větší škody commitnutím škodlivého kódu. Ale zaseknout se trvale na nebezpečné hashovací funkci je podle mne špatně. S SHA-1 je to podobné, jako s HTTPS – je zbytečné nutit uživatele neustále přemýšlet o tom, kde je „nebezpečná“ varianta dostačující a kde je potřeba použít něco bezpečného, když můžu všude používat ty bezpečné algoritmy a protokoly.

    Ošetřit kolize se dá i jiným způsobem včetně podobných kontrol jako tady ve zprávičce.
    To je rychlý hack, ne trvalé řešení. Pak jste pořád o krok za útočníky, na každý nový způsob vytváření kolizí musíte najít způsob jejich detekce a dodatečně je implementovat.