On Tue, Jul 17, 2012 at 8:54 PM, Greg Freemyer
Ignoring the X.509 certificate:
I find it much more troublesome that in most situations the hash comes from the same source as the package/data file. In those situations it is trivial to change the payload file, then just recalculate the hash and update it in the metadata file/source.
The hash *has to* come from the source of the package, the hash is there to avoid tampering in transit. It would be quite trivial to install a proxy between both systems that inserts malicious code into the package. The proposed GPG signatures can stop malicious proxies from recalculating the hashes.
Thus if the hash value itself can't be robustly trusted, there is no reason to worry about collision attacks which require far more resources than an attacker just updating the hash value to match his altered/infected payload file.
And collision attacks for MD5 do not require that many resources. I've carried them out successfully with my lowly Pentium 4 for a security workshop.
My impression is that the proposed solution makes no effort to "sign" the metadata, thus if a attacker is able to access the distribution infrastructure to manipulate the payload, they could manipulate the metadata.
Repos should already have signed metadata. At least I can see the signatures in download.o.o The only weak spot in verifying signatures is key distribution, which OBS cannot implement it 100% trustworthy. But, as I explained, it still is better than mere hashes. And, certainly, SHA-family hashes are way better than MD5.
Thus, other than the X.509 cert I argue that the whole proposed integrity mechanism as I understand it is broken from a authentication perspective no matter what hash is used, MD5 or otherwise.
X.509 is no stronger than GPG signatures. Hashes alone, maybe, but not with GPG-signed metadata. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org