3 ms·

This is concerning from a signing perspective. Example: `git commit -a -S -m 'signed commit'` signs the SHA-1 hash directly. Even if the SHA-1 digest is rehas

This is concerning from a signing perspective. Example: `git commit -a -S -m 'signed commit'` signs the SHA-1 hash directly. Even if the SHA-1 digest is rehashed with a secure hashing algorithm, SHA-256, it would hide the fact that the reference is to an insecure hashing algorithm. The project itself needs to be rehashed with a secure hashing algorithm for signing to be secure.

Dylan16807 4y ago
It's more complicated than that. If the most recent signatures are entirely based on SHA-256, and you trust those signatures sufficiently, then they act as protection for all ancestor commits. In that case a SHA1-based signature on an older commit isn't a big deal.
- Zamicol 4y ago
  >then they act as protection for all ancestor commits How does that work? My understanding was that a git gpg signature only signs the project at that commit state. It says nothing about past (or future) commits outside of a digest reference to past commits, which if that digest wasn't upgraded, would be considered insecure. Said another way: Git does not rehash past commits, or the present commit, when gpg signing. A commit itself only includes the SHA-1 digest of the previous commit.
  - Dylan16807 4y ago
    If you convert a repo to SHA-256, then surely it will recalculate all the hashes back to the start, right? Otherwise that's not a conversion. And then new signatures will use a hash that's SHA-256 all the way down. The old signatures will still be SHA-1. But if you try to replace any part of a commit, the SHA-256 won't match. So the combination of "the commit is an ancestor of multiple securely signed commits in this repo" and "the SHA1 on the signature matches" is enough to know you have the right data in most use cases.
  - layer8 4y ago
    You are correct. In the AdES signature world, the solution is to have a cryptographic (signed) timestamp using a newer hash algorithm that rehashes all previous commits, and to include that timestamp into a new commit. When verifying the hashes of old commits, the software would verify that those are covered by an appropriate timestamp that proves that they were created before the old hash algorithm was considered too weak. This is very similar to the following: Instead of rehashing, i.e. replacing old hashes with new hashes, add the new hashes alongside the old ones, and sign the new hashes, together with the time mark, by a trusted authority. The old hashes and signatures then remain valid indefinitely as long as the new hashes and signatures are verified successfully.

Dylan16807 4y ago

It's more complicated than that. If the most recent signatures are entirely based on SHA-256, and you trust those signatures sufficiently, then they act as protection for all ancestor commits. In that case a SHA1-based signature on an older commit isn't a big deal.

Zamicol 4y ago
>then they act as protection for all ancestor commits How does that work? My understanding was that a git gpg signature only signs the project at that commit state. It says nothing about past (or future) commits outside of a digest reference to past commits, which if that digest wasn't upgraded, would be considered insecure. Said another way: Git does not rehash past commits, or the present commit, when gpg signing. A commit itself only includes the SHA-1 digest of the previous commit.
- Dylan16807 4y ago
  If you convert a repo to SHA-256, then surely it will recalculate all the hashes back to the start, right? Otherwise that's not a conversion. And then new signatures will use a hash that's SHA-256 all the way down. The old signatures will still be SHA-1. But if you try to replace any part of a commit, the SHA-256 won't match. So the combination of "the commit is an ancestor of multiple securely signed commits in this repo" and "the SHA1 on the signature matches" is enough to know you have the right data in most use cases.
- layer8 4y ago
  You are correct. In the AdES signature world, the solution is to have a cryptographic (signed) timestamp using a newer hash algorithm that rehashes all previous commits, and to include that timestamp into a new commit. When verifying the hashes of old commits, the software would verify that those are covered by an appropriate timestamp that proves that they were created before the old hash algorithm was considered too weak. This is very similar to the following: Instead of rehashing, i.e. replacing old hashes with new hashes, add the new hashes alongside the old ones, and sign the new hashes, together with the time mark, by a trusted authority. The old hashes and signatures then remain valid indefinitely as long as the new hashes and signatures are verified successfully.