User talk:Vesath

From ArchWiki

PKGBUILD#Integrity That's interesting, why do you feel that is?

Preimage resistance after all is not collision resistance, and breaking the preimage of MD5 reliably is apparently still in the complexity of 2^123.4 (

--Dettalk 09:45, 25 September 2017 (UTC)

There is simply no reason to prefer weaker hashes over stronger ones. Even if the best currently-known preimage attack on MD5 requires 2^123 operations, there is no reason to believe in the security of MD5 preimages given the terrible security record this hash function has. There are much all-round much better hash functions out there, and that's what they're here for. Using all-round better hashes like sha256 also protects against less-likely but still forseeable attack scenarios like this one: somebody with upstream GIT access pushes innocuous looking commits (no malicious code there) that end up making the tarball hash equal to that of a malicious tarball he's created on the side. --- Vesath (talk) 19:23, 25 September 2017 (UTC)
Regarding "The checksum type and values should always be those provided by upstream, such as in release announcements.": is it just badly worded or does the logic conflict with the existence of the updpkgsums script in the pacman package? Packagers can be either expected to verify the checksums with upstream, or be allowed to use the updpkgsums script for convenience to generate the checksums from the local copy of the files.
I don't think this situation can be described as a "common misconception", it seems more like a flamewar between two sides of more or less the same strength, one saying that md5 is so insecure that it should never be used and the other that even md5 is perfectly safe for integrity verification. I don't want to take sides in it, but if there is a consensus among the devs on this, I think it would be much more effective to express it on the PKGBUILD(5) manual page or with an adjustment of makepkg's features (like the default checksum to generate with -g etc.).
-- Lahwaacz (talk) 20:43, 25 September 2017 (UTC)
updpkgsums should only be used for packages that use digital signatures to verify the authenticity and integrity of the tarball they are built from. In that case, when digital signatures are checked, the hash arrays serve no purpose. However, when upstream does not digitally sign their releases, hashes are they only thing we have to ensure:
  • The tarball we build from is the same when the person who updates the package first downloads it and when others later download it again. That's integrity.
  • The tarball we build from originates from upstream, for instance because its hash was published in the release announcement. This requires more work to check on the part of the person who updates the package, but provides authentication. For this, we need to use the hash as published by upstream. Note that we can have several hash arrays, so if upstream only publishes md5sums, we can have those in the PKGBUILD along with sha256sums (for stronger integrity).
I hope the above clears up some confusion around what hash arrays are actually useful for. There will probably be no change to PKGBUILD(5) because pacman's policy has always been that it's a general-purpose project, not an Arch-specific project, so they do not want to make distro's choices for them. Since I don't think it's worth customizing our pacman PKGBUILD for this, the wiki seems to me the perfect place to reflect these recommendations. --- Vesath (talk) 21:25, 25 September 2017 (UTC)
> I hope the above clears up some confusion around what hash arrays are actually useful for.
I would've hoped so too. No.
Is there a source for your claim as to the breakage of collision resistance of MD5 implies forseeable preimage exploits as well? And why do you think it makes any sort of practical sense to include multiple hashes in a PKGBUILD for "stronger intergrity" (sha256sums along with md5sums)? This implies SHA-256 would be somehow easier to break than MD5, which is also a claim I'd like to see being made elsewhere.
p.s. Don't go editing the Wiki on your own before this is concluded. And definitely not with a description of "remove common misconceptions"[1] (as if this just proved collision vs preimage resistance), even though still better than the "The old recommendations were terribly retarded".[2] ^^
Dettalk 06:09, 26 September 2017 (UTC)
No idea why you're using that tone but if that's how you think discussing works I'm done talking to you. As an Arch developper and crypto researcher, I also don't have to prove anything to you. And I'll keep editing this wiki as I see fit, thank you. --- Vesath (talk) 07:04, 26 September 2017 (UTC)
What is the "tone" I gave you besides asking for a source? If you don't give out a source, then it's very difficult to try and verify your claims. ^^
Linus Torvalds codes Linux, but guess what. Sometimes, he's wrong about kernels. So, just give a link and that's it.
Dettalk 07:13, 26 September 2017 (UTC)
When an attack is designed against a hash function that substantially breaks one of its original security claims (e.g. collision resistance), the general implication is that the hash function design was fundamentally flawed, so there is no reason to expect other security claims (e.g. preimage resistance) to hold any better than the attacked one did. That's considered common sense among cryptographers. We might have kept recommending MD5 for applications that *only* require preimage resistance if there was no other choice. But there are: we have plenty of much better hash functions, so let's use them whenever possible. For a source, let me quote Wikipedia's page on MD5: "As of 2010, the CMU Software Engineering Institute considers MD5 "cryptographically broken and unsuitable for further use", and most U.S. government applications now require the SHA-2 family of hash functions." (Everybody in crypto has been recommending this for nearly a decade.)
As to your other question, I never claimed that SHA256 was weaker than MD5, quite the opposite. I'm just pointing out that if upstream only publishes their release tarballs' md5sums, then that hash should be used because it allows some form of authentication: you can verify that the tarball you get is what upstream advertised in their release announcement. (To the extent that MD5 is secure, of course, but in that case I'm assuming it's all we've got.) But then you might also want to add a stronger hash in addition to md5, say sha256, in order to better protect the integrity of the file you downloaded. PKGBUILDs indeed support multiple hashes and this way your package is as secure as the strongest hash.
Cheers. --- Vesath (talk) 07:39, 26 September 2017 (UTC)
All right. Seems that sentiment is indeed echoed in security/ [3][4][5], and how the speed of MD5 is actually a flaw. Maybe still not buying the practical need of the multiple hashes, but I get the intent of even stronger integrity.
Dettalk 07:49, 26 September 2017 (UTC)