A opravdu používáte v roce 2025 ke kontrole integrity souborů MD5?
Ale používat MD5 pro kontrolu integrity souborů nedává smysl. Třeba BLAKE3 je bezpečnější a rychlejší.A opravdu používáte v roce 2025 ke kontrole integrity souborů MD5?
Ke kontrole integrity souboru staci klidne CRC-32, ale s MD5 je to lepsi.
Phase-out MD5 nastal pouze pro kryptograficke ucely (podepisovani, HMAC, atd).
MD5 samozřejmě pro kontrolu integrity smysl dává, ale je pravdou, že BLAKE3 je výrazně rychlejší, blíží se rychlostí CRC32.
Rychlost při hashování 1 GB souboru:
Algoritmus Čas (přibližně)
BLAKE3 ~0.3 s
CRC32 ~0.2 s
MD5 ~1.0 s
SHA-1 ~1.5 s
SHA-256 ~2.5 s
RIPEMD-160 ~3.0 s
Jinak bych si myslel, že může být problém s CPU, cache, přetaktováním, napětím CPU ...
- diff použitý na zip stažený wgetem (na serveru) a souborem poslaným na server přes scp hlásí, že se liší
echo 3 | sudo tee /proc/sys/vm/drop_caches
wget volám úplně obyčejně, ale k přerušování spojení dochází (na notebooku ne).
Soubory na serveru z různých pokusů mají shodnou velikost, ale rozdílné md5. Budu je ještě muset převést do podoby porovnatelné diffem.
Co jsem stihl vyzkoušet:
- stažení za použití live distro (konkrétně USB flash s Gparted) na shodném HW: md5 sedí(!)
- znovu stažení na ntb, ověření md5 (tady samozřejmě sedí) a v terminálu scp na server - md5 nesedí(!)
- diff použitý na zip stažený wgetem (na serveru) a souborem poslaným na server přes scp hlásí, že se liší
Neděláš ten MD5 moc brzy po stažení? Jen jestli se ti to ještě na ten disk všecko z těch všech keší po cestě fyzicky zapsalo.
A taky, co já vim, čistě náhodou, při tom downloadu, neměníš někdy vlastníka, práva, pravidla spouštění, apod?
A dělá ti to stejně pod userem i pod rootem? Co jinej, novej user?
Neděláš ten MD5 moc brzy po stažení? Jen jestli se ti to ještě na ten disk všecko z těch všech keší po cestě fyzicky zapsalo.
Tak anabáze bohužel nekončí. Mám půjčený zánovní 400W zdroj a dospěl jsem k tomuto:
- v konfiguraci s SSD a jedním HDD šlo stahování vždycky bez přerušení, md5 sedí
- jakmile připojím druhý HDD (zkoušel jsem i různé kombinace portů - nemají na to vliv), začne se stahování přerušovat, md5 nikdy nesedí
Pokud je SATA i to SSD, pak bych se obával o osud kontroleru jednoho z těch HDD.Jo, vítejte v klubu. Něco na tohle téma (plus v další fázi i dost podivný pokles FPS na grafice za nepredikovatelných podmínek) mě loni donutilo k upgradu boardu(+CPU).
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůžePomůže. Třeba když bude chyba na tom samém místě, kde se přerušilo stahování. Nebo bude vždy na stejném místě. Nebo bude chyba spočívat v tom, že tam budou jen nulové bajty.
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůže
Za me je k dalsimu hledani chyby (tj. vetveni - je to sitovka nebo je to disk) by pomohlo kdyby jste data na obou koncich spoje (jestli je mate tedy ve vlastni rezii) ukladal/stahoval/sdilel pouze z ramdisku (tj /dev/shm ). To pak rekne zda to je disk nebo sitovka. (za me sit/sitovka je pravdepodobnejsi, protoze chybnej disk by se taky projevil segfaultama aplikaci).
# zapis+verifikace
fio --name=write --filename=testfile --rw=write --size=1G --bs=4k \
--direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1
# samostatna verifikace
fio --name=verify --filename=testfile --rw=read --bs=4k \
--direct=1 --ioengine=libaio --verify=pattern --verify_pattern=0xDEADBEEF --verify_fatal=1
# kontrola zapsaneho souboru hexdumpem (skipuje vsechny opakujici se radky, takze je hned videt chyba)
hexdump -C testfile
00000000 de ad be ef de ad be ef de ad be ef de ad be ef |................|
*
40000000
# zapis s vlozenym crc kodem a verifikace
fio --name=crcwrite --filename=testfile2 --rw=write --size=1G --bs=4k \
--direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1
# samostatna verifikace crc
fio --name=crcverify --filename=testfile2 --rw=read --bs=4k \
--direct=1 --ioengine=libaio --verify=crc32c --verify_interval=4k --verify_fatal=1
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůžePokud pocitac jinak nepada, tak bych treba vadnou RAM vyloucil. Protoze pokud hitnete stahovani dat s chybou, tak by vam ty appky padali viditelne jako hnile hrusky na segfault, [...] protoze chybnej disk by se taky projevil segfaultama aplikaci).
- na diff se chystám, ale ten nám přece řekne, kde je chyba v souboru, ne? A vzhledem k tomu, že každý ze stažených souborů (teď už jich mám asi 12) má jiný checksum, nevím, jestli nám to něco pomůžePokud pocitac jinak nepada, tak bych treba vadnou RAM vyloucil. Protoze pokud hitnete stahovani dat s chybou, tak by vam ty appky padali viditelne jako hnile hrusky na segfault, [...] protoze chybnej disk by se taky projevil segfaultama aplikaci).
To není ani náhodou jisté. Zcela nedávno jsem řešil, že mi v notebooku odešel jeden modul RAM. Shodou okolností horních 16 GB. Projevovalo se to tak, že dokud nebyl spodní modul plný, aplikace nepadaly, alokovaly evidentně zespodu adresního prostoru. A neprojevovalo se to ani na diskové cache protože ta se také udržela ve spodní části paměťi. Jakmile ale došlo k zaplnění, aplikace se postupně jednak staly nestabilní a druhak začaly sem tam vznikat chyby ve filesystému kvůli diskové cache v té vadné horní polovině adresního prostoru, odkud občas přišly chybné bajty.
Celé jsem to odhalil až asi za měsíc a to jsem ten notebook intenzivně používal denně. Do té doby se to projevovalo tak, že sem tam občas prostě něco spadlo (typicky prohlížeč, ten je paměťově náročný) a občas byl poškozený filesystém. Od výměny selhávajícího modulu je vše OK. Takže na ty segfaulty bych se nutně fakt nespoléhal. Problém klidně může být třeba v konkrétním úzkém adresovém bloku paměťi využívaném pro DMA. Nebo třeba v IOMMU. Nebo kdekoliv mezitím.
Záleží na účelu.
Tam kde jde o bezpečnost (hashe hesel) máte pravdu.
Ale tam, kde jde jen o technickou kontrolu shody/neshody dvou souborů, se pořád běžně používá (jako alternativa CRC32).
Jednak MD5 není „normální nekryptografický hash“, ale prolomený kryptografický hash. Jednak u u souborů vystavených na internetu se hash nezveřejňuje proto, aby se odhalila chyba v hardwaru, ale především jako ochrana před změnou souboru. Třeba když je soubor vystaven na různých zrcadlech, ale hash bych si měl stáhnout přímo od zdroje, nebo alespoň z jiného zrcadla.
Ale hlavně – i když mi stačí hash, na který nejsou kryptografické nároky, nebudu používat MD5. Použiju třeba BLAKE3, která je podstatně rychlejší, než MD5.
Že někdo pořád vystavuje u souborů určených pro stažení hashe v MD5 je stejná ostuda, jako když distribuce ještě spoustu let po té, co byl linuxový ifconfig označen jako zastaralý, používaly pro konfiguraci sítě ifconfig místo ip.
Že někdo pořád vystavuje u souborů určených pro stažení hashe v MD5 je stejná ostuda, jako když distribuce ještě spoustu let po té, co byl linuxový ifconfig označen jako zastaralý, používaly pro konfiguraci sítě ifconfig místo ip.
A nenapadlo vás, že je to proto, že to prostě stačí? Fakt myslíte, že ve zcela drtivé většině případů někoho trápí, jestli se mu těch pár desítek mega nebo i pár giga ověřuje pět vteřin nebo desetinu vteřiny? Nebo že s pravděpodobností jedna ku opravdu hodně nul může jít o kolizi?A nenapaldo vás, že není důvod dělat to blbě, když to jde dělat i lépe – bez jakýchkoli nákladů? Kdyby vám v obchodě nabídli úplně to samé zboží, jendou za 100 Kč a podruhé za 150 Kč, v regálu vedle sebe, identické balení, prostě všechno stejné – budete si kupovat to dražší, protože to prostě stačí?
A nenapadlo vás, že je to proto, že to prostě stačí? Fakt myslíte, že ve zcela drtivé většině případů někoho trápí, jestli se mu těch pár desítek mega nebo i pár giga ověřuje pět vteřin nebo desetinu vteřiny? Nebo že s pravděpodobností jedna ku opravdu hodně nul může jít o kolizi?A nenapaldo vás, že není důvod dělat to blbě, když to jde dělat i lépe – bez jakýchkoli nákladů?
Když to stačí, tak to hlavně logicky není důvod vůbec řešit. Většinu lidí zajímají důležitější věci než tohle. A pak jsou samozřejmě lidé, co řeší podobné věci a uniká jim pointa, ehm, že... Zlý jazyk by je mohl nazvat takovými intelektuálními nebo technickými snoby. Nebo třeba lidmi odtrženými od reality.Řešit to pokaždé musíte vy. Pokaždé musíte zkoumat, jestli v daném případě MD5 stačí nebo nestačí. Já nic řešit nemusím, protože já MD5 nepoužívám nikdy.
Já nic řešit nemusím
A v čem přesně nemám pravdu?
Pokud se původnímu tazateli samovolně mění hash souborů, tak jde o chybu HW a ne zásah hackerů, nebo ano? V tomto případě úplně v pohodě stačí kontrola MD5 či XXHASH, nebo CRC32. Jestli jde o rychlost, tak poslední dva jsou rychlejší než BLAKE3.
Nikde nepíše, že má ten originální md5 součet někde z internetu. Já teda předpokládal, že si stáhl soubor na notebook, udělal md5. Stáhl soubor na server, udělal md5 - no a tyto dva součty se lišily.
Jestli chcete odevšad vyházet nekryptografické hashe, no tak asi by bylo dobré začít třeba od BTRFS, který používá "prolomený" CRC32.
Jednalo se o instalační zip Nextcloudu. Ten nejnovější. Nabízejí k němu MD5, tak jsem jej použil i jáNejvětší problém je v tom, že autoři Nextcloudu nemají dost soudnosti na to, aby MD5 přestali nabízet. No a že tam mají MD5 a nemají třeba BLAKE3…
Zkoušeno mnohokrát, čímž se pravděpodobnost kolize dále snižuje.Nesnižuje. U MD5 není problém v tom, že by kolize mohla vzniknout náhodou. Problém je v tom, že se velmi snadno dá vyrobit záměrně. Pokud by někdo nahrálna server falešný soubor, ke kterému by však seděl MD5 součet, nezáleží na tom, kolikrát to budete zkoušet – pořád tam bude ten stejný (podvržený) soubor, takže výpočet jeho MD5 vyjde pokaždé stejně.
Zkoušeno mnohokrát, čímž se pravděpodobnost kolize dále snižuje.Nesnižuje. U MD5 není problém v tom, že by kolize mohla vzniknout náhodou. Problém je v tom, že se velmi snadno dá vyrobit záměrně. Pokud by někdo nahrálna server falešný soubor, ke kterému by však seděl MD5 součet, nezáleží na tom, kolikrát to budete zkoušet – pořád tam bude ten stejný (podvržený) soubor, takže výpočet jeho MD5 vyjde pokaždé stejně.
Nejde o to, že by zrovna v tom vašem způsobu použití, kdy jste hledal chybu hardwaru, mohlo MD5 způsobit nějaké problémy. Jde o to, že především autoři Nextcloudu ten MD5 hash vůbec nemají vystavovat, a za druhé i vy byste měl automaticky sáhnout po něčem jiném, než MD5. Stejně jako pro konfiguraci sítě na Linuxu automaticky saháme (doufám, že už všichni) po ip a ne po ifconfig.
On md5 pouziva na detekci chyb a ne na detekci podvrhu. A vy dva s Crhonkem si zalozte vlastni vlakno a nepodsouvejte mu vlastni nemohoucnost pochopit use case.
Máte to vysvětlené v tom textu, který jste citoval. První dvě věty máte vysvětlené v prvním odstavci, třetí větu ve druhém.Zkoušeno mnohokrát, čímž se pravděpodobnost kolize dále snižuje.Nesnižuje. U MD5 není problém v tom, že by kolize mohla vzniknout náhodou. Problém je v tom, že se velmi snadno dá vyrobit záměrně. Pokud by někdo nahrálna server falešný soubor, ke kterému by však seděl MD5 součet, nezáleží na tom, kolikrát to budete zkoušet – pořád tam bude ten stejný (podvržený) soubor, takže výpočet jeho MD5 vyjde pokaždé stejně.
Nejde o to, že by zrovna v tom vašem způsobu použití, kdy jste hledal chybu hardwaru, mohlo MD5 způsobit nějaké problémy. Jde o to, že především autoři Nextcloudu ten MD5 hash vůbec nemají vystavovat, a za druhé i vy byste měl automaticky sáhnout po něčem jiném, než MD5. Stejně jako pro konfiguraci sítě na Linuxu automaticky saháme (doufám, že už všichni) po ip a ne po ifconfig.
To vis, ze snizuje. On md5 pouziva na detekci chyb a ne na detekci podvrhu. A vy dva s Crhonkem si zalozte vlastni vlakno a nepodsouvejte mu vlastni nemohoucnost pochopit use case.
Zkoušeno mnohokrát, čímž se pravděpodobnost kolize dále snižuje.Nesnižuje. U MD5 není problém v tom, že by kolize mohla vzniknout náhodou. Problém je v tom, že se velmi snadno dá vyrobit záměrně. Pokud by někdo nahrálna server falešný soubor, ke kterému by však seděl MD5 součet, nezáleží na tom, kolikrát to budete zkoušet – pořád tam bude ten stejný (podvržený) soubor, takže výpočet jeho MD5 vyjde pokaždé stejně.
Pokud si prectes vlakno, tak zjistis ze OP nezapasi s tim, ze mu stazeny soubor zobrazuje cunarny a tezi bitkojny, byt mu MD5 sedi.. ale tim, ze mu MD5 praveze nesedi !Pokud si přečtete vlákno, zjistíte, že původní problém byl dávno vyřešen.
Nechapu tu potrebu resit porad nejake off topic veci. Drz se tematu nebo si zaloz vlastni.
Pokud chci porovnávat jen okometricky, tak je dobré vzít v úvahu i délku výsledného hashe.
Přece jen je rozdíl koukat na řetězce typu (a hledat rozdíl):
CRC32 - B7781039
MD5 - 3d166650cb8991f23a1b9f77b1f4901c
BLAKE3 - 28b5122d0aea9630ba3421baf150fa08ff05d34bf7209575db3056da8fa7f62f
Ano, to že jsou rozdílné, obvykle poznám stejně rychle u všech.Pokud si potřebujete být opravdu jist, nebudete to porovnávat očima. Pokud vám ale stačí porovnání očima a zvládnete porovnat 32 hexadecimálních znaků MD5, pak zvládnete porovnat i prvních 32 hexadecimálních znaků BLAKE3 – a pořád budete mít u BLAKE3 nesrovnatelně větší jistotu, než u MD5.
Ale zda jsou opravdu shodné, to už ne - jedině, že bych kouknul na prvních 5 znaků a když jsou shodné, zbytek nečtu a neporovnávám - ale pak mi stačí i ten CRC32, když zbytek ignoruju.
Pokud si potřebujete být opravdu jist, nebudete to porovnávat očima. Pokud vám ale stačí porovnání očima a zvládnete porovnat 32 hexadecimálních znaků MD5, pak zvládnete porovnat i prvních 32 hexadecimálních znaků BLAKE3 – a pořád budete mít u BLAKE3 nesrovnatelně větší jistotu, než u MD5.
Podle @corkami není prakticky možné vytvořit soubor s konkrétním MD5 hashem.
To není pravda. Avalanche efekt je u obou velmi podobný (rozdíl je pouze nějakých 1-2pb).Co na tom není pravda? Pravděpodobnost, že budou mít dva soubory náhodou stejné MD5 je stejná, jako že budou mít stejnou první půlku BLAKE3 hashe (protože BLAKE3 je náhodou dvojnásobná oproti MD5). Podstatné je, že obojí je extrémně malá pravděpodobnost. Avalanche efekt se uplatňuje proto, že to nejsou dokonalé hashovací funkce – ale to je vzhledem k té pravděpodobnosti shody zanedbatelné.
BTW Podle @corkami není prakticky možné vytvořit soubor s konkrétním MD5 hashem. Tj. pokud máte bezpečnou cestou předaný MD5 k původnímu souboru, který nebyl(!) vyrobený za účelem MD5 kolize, tak se lze na MD5 spolehnout (s ohledem na konkrétní použití)Nikoli, MD5 už je dávno prolomené vůči kolizím prvního i druhého řádu. Kolize druhého řádu byla na MD5 v praxi předvedena už v roce 2008. Ano, potřebovali k tomu tenkrát výkonný cluster, ale byl to rok 2008. V roce 2012 byl dle Microsoftu podepsán malware Flame certifikátem s kolizním hashem. Takže minimálně od roku 2012 musíte považovat kolize druhého řádu u MD5 za běžně dostupné.
To vis, ze snizuje. On md5 pouziva na detekci chyb a ne na detekci podvrhu. A vy dva s Crhonkem si zalozte vlastni vlakno a nepodsouvejte mu vlastni nemohoucnost pochopit use case.
(https://i.ibb.co/5XZG36qF/1534957079326.gif) (https://imgbb.com/)Ten nahoře je slam-němý panák a a dole je MD5 a mlátí ji kolizí druhého řádu ale díky avalanche štítu se vyhýbá té slámě.
Škoda jen toho použitého hashe :)
Ten nahoře je slam-němý panák a a dole je MD5 a mlátí ji kolizí druhého řádu ale díky avalanche štítu se vyhýbá té slámě.
To není pravda. Avalanche efekt je u obou velmi podobný (rozdíl je pouze nějakých 1-2pb).Co na tom není pravda? Pravděpodobnost, že budou mít dva soubory náhodou stejné MD5 je stejná, jako že budou mít stejnou první půlku BLAKE3 hashe (protože BLAKE3 je náhodou dvojnásobná oproti MD5).
BTW Podle @corkami není prakticky možné vytvořit soubor s konkrétním MD5 hashem. Tj. pokud máte bezpečnou cestou předaný MD5 k původnímu souboru, který nebyl(!) vyrobený za účelem MD5 kolize, tak se lze na MD5 spolehnout (s ohledem na konkrétní použití)Nikoli, MD5 už je dávno prolomené vůči kolizím prvního i druhého řádu. Kolize druhého řádu byla na MD5 v praxi předvedena už v roce 2008. Ano, potřebovali k tomu tenkrát výkonný cluster, ale byl to rok 2008. V roce 2012 byl dle Microsoftu podepsán malware Flame certifikátem s kolizním hashem. Takže minimálně od roku 2012 musíte považovat kolize druhého řádu u MD5 za běžně dostupné.
Reagoval jsem na vaše tvrzení, že „pořád budete mít u BLAKE3 nesrovnatelně větší jistotu, než u MD5.”Za předpokladu, že útočník může ovlivnit obsah zdrojového souboru, aby mohl provést útok nalezením kolize, nemáte u MD5 jistotu, že se soubory neliší.
Máte pro své tvrzení nějaký důvěryhodný zdroj? Ne, že bych to problematiku podrobně sledoval, ale stále mi výsledky hledání hlásí i pro rok 2025 prakticky nedosažitelný second-preimage MD5 attack (dokonce se mi tu někde mihlo, že to nejde ani pro MD4). Pochopitelně se bavíme o běžných velikostech zpráv/souborů. Nikoli „laboratorní” jednotky bajtů.Máte pravdu. Nepozorně jsem si to přečetl – ty certifikáty nebyly vytvořené jako dvojčata k již existujícím certifikátům, ale útočníci/útočníci si nechali vystavit certifikát, následně v něm změnili některé atributy ale výsledek měl stejný hash, takže na modifikovaném certifikátu byl stále validní podpis CA. Pre-image útok proti MD5 byl navržen v roce 2009, ale zůstává stále jen teoretický kvůli velké výpočetní složitosti. Omlouvám se za mystifikaci.
Pokud chci porovnávat jen okometricky, tak je dobré vzít v úvahu i délku výsledného hashe.
Přece jen je rozdíl koukat na řetězce typu (a hledat rozdíl):
CRC32 - B7781039
MD5 - 3d166650cb8991f23a1b9f77b1f4901c
BLAKE3 - 28b5122d0aea9630ba3421baf150fa08ff05d34bf7209575db3056da8fa7f62f
Podstatnym kvalitativnim ukazatelem dobreho hashe je, ze i pri zmene byt jednoho bitu, bude cely hash vypada uplne jinak :) Takze nezalezi na delce.. zmena bude patrna uz z prvnich (ci poslednich) cislic. (ostatne to je princip i zkracovani u git commit hashe)Bavíme se o náhodné kolizi prvních/posledních pár bytů, nebo o cílené kolizi? Cílenou kolizi pár bytů uděláte hrubou silou. U sedmimístného git commit id máte 4*7 = 28 bitů, to je s brute force hračka, to spočítáte dnes snad i na hodinkách. Pokud můžete měnit něco na konci souboru, dokonce ani nemusíte pokaždé počítat hash od začátku, ale můžete podstatnou část výpočtu sdílet.
Reálné útoky se tedy spíš soustředí na to, aby nebylo potřeba najít jiný pre-image, ale jen obyčejnou kolizi. Nevím, jestli je k tomu prakticky použitelná samotná knihovna třetí strany, spíše nějaká binární data jako třeba obrázek. Nebo něco, kam lze skrýt vhodná metadata, aniž by to bylo někomu divné.Je úplně jedno, zda to bude obrázek nebo binárka knihovny. Akorát že obrázků z externích zdrojů Nextcloud asi moc nemá, externí knihovny určitě používá.
Tak evidentně problém s kolizí MD5 původní autor nemá, spíš naopak, že? :-)Pardon, že vstupuji tak pozdě, ale opravdu je v celém vlákně řeč o tom, že kontrola MD5 je špatně, protože nějakej hypotetickej útočník, kterej dokáže na webu změnit package.deb tak, aby dosáhl kolize (pamatuji, že pan Klíma předvedl, že je potřeba pro kolizi mít volných 32 bitů padu, kterýma se předchozí změna 32 bitů "srovnala" nebo tak nějak nejlepší útok vypadal), takže magickým způsobem když místo package.deb.md5 tam dáme package.deb.sha384 (předpokládám, že většina diskutujících tuší, proč ne rovnou 512), tak nějakým zázrakem ten samej útočník nedokáže ten *.sha384 prostě přepsat jako tu původni package?
Původní otázka: "stáhnu přes wget soubor a nesedí md5"
Kam jsme došli: "md5 je outdated, je snadné (???) vytvořit jiný soubor se stejným md5, musí se použít XXX nebo YYY, což je free-cool-in a moderní"
Tak evidentně problém s kolizí MD5 původní autor nemá, spíš naopak, že? :-)
Pardon, že vstupuji tak pozdě, ale opravdu je v celém vlákně řeč o tom, že…Ne, není.
Ne, není.Ale ano, je. Tak, jak to dělají ve zmíněném NextCloudu je naprosto správně a používají daný hash přesně způsobem, kde dává smysl (integrita), a nepoužívají ho tam, kde smysl nedává (gpg pokud se nepletu používá pro signaturu v defaultu sha256, který je k tomu vhodný), stačí číst místo dogmatického svatého boje.)
Download the .tar.bz2 or .zip archive.
Check package integrity using MD5 (.tar.bz2 / .zip) or SHA256 (.tar.bz2 / .zip)
Verify the authenticity via PGP (.tar.bz2 /.zip). The Nextcloud GPG key is here. You can also grab the keys by issueing this command:
gpg --keyserver keys.openpgp.org --recv-keys 28806A878AE423A28372792ED75899B9A724937A
Tak, jak to dělají ve zmíněném NextCloudu je naprosto správněNení. Hash souboru se používá i tak, že si jej stáhnete důvěryhodnou cestou, a samotný soubor už pak můžete stáhnout jakkoli a na závěr jenom ověříte jeho hash.
používají daný hash přesně způsobem, kde dává smysl (integrita)Použití MD5 v takové situaci stejně smysl nedává, už to tu bylo vysvětleno několikrát.
nepoužívají ho tam, kde smysl nedáváKdyž někde vystaví GPG klíč, mohou tam úplně stejně vystavit hash (vytvořený neprolomeným algoritmem) a bude to mít úplně stejnou funkci.
tl;dr Proti chybě chrání dostatečně prakticky cokoli, nejen md5, ale klidně i half-md4, jen do crc32 bych nešel (1:4miliardy je sice dostatečně malá šance i tak, ale muselo by se vyloučit, že kdekoli, kudy ty data tečou na jakékoli architektuře, není použitej stejnej crc32, jinak by to jen potvrdilo chybu...), pro ověření je potřeba použít kryptograficky silný hash.Akorát nedává smysl používat jeden prostředek na zajištění integrity a druhý prostředek na integrity+autenticity, protože integrita+autenticita v sobě integritu zahrnuje.