Hi, I agree with Bernd, checksums are there to validate the consistency of the artifact, nothing linked to security. On central the security side is provided by the asc file which is sufficient if you trust only allowed releasers keys in practise, pretending you are a releaser will be quite hard so this is likely the best security you can setup as of today and no checksum algorithm can make it stronger (it is 1-1 in terms of security).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 14 oct. 2021 à 09:56, Mickael Istria <[email protected]> a écrit : > On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels <[email protected]> > wrote: > > > There is no Security risk with weaker checksums since the checksums are > > not used for security. An attacker who messes with your binaries can also > > mess with the checksum files. > > > In our case, we have the checksum files that are served from a "trusted" > place, but the artifacts can come from less trusted mirrors. And we want to > ensure the artifact we get is the one we expect whichever server does serve > it. Checksums can do that, and broken checksums algorithms such as md5 or > sha1 can allow a mirror to forge a malicious artifact with the same > checksums and thus let a malicious artifact be installed in place of a good > one; while strong checksums algorithms don't allow that. > > > > Only the signatures are relevant here (and they depend on the PGP > settings > > if they use strong hashes). > > > > I disagree that from a security perspective signatures have any stronger > impact on securing the transfer than a good checksum. Signatures are here > to create a concept of "trust delegation" (I trust this artifact because X > has signed they trust it), it's basically meant for human decision, not for > automated artifact transfer verification. > > And even the broken/short/fast md5 would be strong enough to detect bit > > errors, especially considering TLS is now mandatory. > > > > See my point above; it's not only a bit error, it can be malicious > artifacts coming from another source (mirror) and pretending to be the > correct ones because md5 is weak enough to allow to do it. >
