Vlákno názorů k článku
NIST oficiálně označil algoritmus SHA-1 za zastaralý, přejděte na SHA-2 nebo SHA-3
od Smazaný profil - Bude to nějak řešit git?
-
tohle tak snadno nelze v contextu toho, že ten commit není osamocený, ale je potřeba, aby byl součástí repa. Přechod na sha-256 se řeší spousty let, ono to je v gitu tak trochu hardcoded hodně těsně, viz třeba https://github.com/git/git/commit/0ed8d8da374f648764758f13038ca93af87ab800
-
Jan HrachStříbrný podporovatelNo nevím, preimage furt nejsou ani na MD5, takže ty asi budou hodně složité. (samozřejmě tím neobhajuju používání prolomené kryptografie, jen je vhodné si uvědomit co jde a co ne)
-
Jan HrachStříbrný podporovatel
Pozor že kolize jsou buď identical prefix nebo chosen prefix (vysvětlení a mnoho příkladů viz https://github.com/corkami/collisions). Edit: a já jsem si myslel že u SHA1 je jen identical, ale ono je i https://sha-mbles.github.io/, takže nic a máš pravdu :)
18. 12. 2022, 17:30 editováno autorem komentáře
-
Tak lokalne si "utocnik" moze vyrabat co len chce, k tomu aby ovplynil ostatnych, to musi pushnut do repoziataru. Teda musi donutit git na strane serveru zaradit svoj commit do stromu na strane serveru. To sa mu len sfalsovanim identifikatoru commitu nepodari. SHA1 v tomto pripade nevystupuje ako bezpecnostna funkcia ale ako identifikator.
-
Smazaný profil
Dvě citace z textu (a diskuze pod ním), který poslal Někdo:
> Adding my own 0.02, what some of us are facing is resistance to adopting git in our or client organizations because of the presence of SHA-1. There are organizations where SHA-1 is blanket banned across the board - regardless of its use. [...] Getting around this blanket ban is a serious amount of work and I have very recently seen customers move to older much less functional (or useful) VCS platforms just because of SHA-1.
> Git signs the commit or tag object, not the whole file tree. So if you don't trust SHA-1, GPG doesn't add any security - the file content under a signed commit or tag could still be replaced.
-
Vysvětlím co znamená "There are organizations where SHA-1 is blanket banned across the board - regardless of its use." - prostě jsou organizace, kde nehodlají zkoumat, jakým způsobem se kde SHA-1 používá; možná i proto, že si uvědomují, že na skutečně kvalifikovaný výzkum nemají kapacity. Takže "better safe than sorry" - prostě ve chvíli, kdy se u SHA-1 ukázal problém, tak pro jistotu používání SHA-1 zakázali plošně.
-
Já to chápu. I když to tedy trochu zavání korporátem a "v časopise pro manažery psali, že SHA-1 je špatná tak ji zakazuju". A stejně tak to nic nemění na tom, že umožnit v Gitu používat další hashovací funkce by taky nebylo na škodu, třeba i z tohoto důvodu.
18. 12. 2022, 12:17 editováno autorem komentáře
-
Jan HrachStříbrný podporovatel
Ano, také mi to přijde divné, doufám že také zakazují CRC-32 ve svých harddiscích.
Napadá mě opodstatnění že se snaží bránit před chybou kdy si někdo řekne "je to kryptografický hash, tak ho tak použiju". Ale stejně zní trochu komicky, pokud místo toho nejspíš používají nějaký jiný VCS který identifikace commitů hashem nemá vůbec :)
-
Ono je na tom komické i to, že lidé ani kolikrát netuší, kde všude se SHA-1 nebo i MD5 používá. Snaha vyhnout se tomu je proto marná hned dvakrát: zaprvé ani neví, čemu se vlastně vyhýbat, zadruhé je to kolikrát nemožné.
Například by mě zajímalo, zda vědí, kterým filesystémům se vyhnout? Kterým databázím se vyhnout? Podle mě nevědí, protože je ani nenapadne, že by se pro generování UUID mohl použít MD5 nebo SHA-1.
