PHAR签名如何防止篡改文件？

Question

I am wondering if it is possible to reuse a signature of a PHAR file. As it is described in the manual , each file has a manifest, which contains a lot of things which can be faked, and 4 bytes of CRC32 checksum, which is a poor choice (md5 or sha1 would be much secure), but can be faked harder than other stuff. I have doubts about the validity of checksum used by creating the signature for verifying. I mean it is slow to create a checksum by every inclusion of the phar file, but adding a manifest cache, which contains the checksum is not an option, if you want to stay secure (because it is relatively easy to modify this cache, if it is stored in the phar file). Do you know how phar packages solve this in a fast way?

Answer 1

The documentation is rather hard to follow, and in some places out of date, but the verification seems to be as follows:

• all files, even those in Tar or Zip format contain a manifest with a CRC check for basic self-validation; this is not tamper-proof, but will detect things like incomplete downloads
• files in the PHAR format can also contain a signature in one of several formats chosen by the creator
• as of PHAR 2.0 (PHP version unclear), the signature can also use an OpenSSL public-private key pair
• this signature is calculated on the whole contents of the archive , independent of the manifest, so can be trusted to detect tampering if it, or the public key, is distributed over a trusted channel

Your question talks of the speed of the signing and verifying process, and this is a key part of your suspicion that an insecure algorithm might be in play. Wikipedia summarises the performance of SHA-256/512 as 200 to 300 MiB/second on an inexpensive 64-bit CPU. Since a PHAR archive is unlikely to be as large as 200MiB, and since signature verification is performed on-demand, not on every execution (at least, I think so), the fraction of a second to hash the whole file is unlikely to be an issue. (Creation of the signature can also be postponed until all files are added, so again has no requirement for higher speed.)