Add SHA-512 support

[fghanmi]

Issue #, if available: #813

Description of changes:
Currently only SHA-256 is supported. This PR is going to:

• Implement SHA-512 support alongside the existing SHA-256.
• Ensure backward compatibility with existing systems that rely on SHA-256.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jpculp]

Thank you for the contribution! I'm going to get some extra eyes on this as well as your other PR.

[jpculp]

Looks like you're hitting some clippy lints. If you run make build with the latest stable Rust as the default you'll be able to verify locally.

[jpculp]

@fghanmi, would it be possible to include a unit test for this change? We can also have someone on our end take care of it if you'd prefer.

[jku]

The root metadata in tough/tests/data/tuf-sha512/metadata/ is still expiring next month

[jpculp]

Hi @fghanmi. Thank you for your patience on this. I think we're in a good place here. Would you be willing to squash your commits to one for the tough changes and one for tuftool? We can also do it on our end if you would prefer.

[fghanmi]

Hi @fghanmi. Thank you for your patience on this. I think we're in a good place here. Would you be willing to squash your commits to one for the tough changes and one for tuftool? We can also do it on our end if you would prefer.

@jpculp , Thank you!
regarding the squash, I see that the changes on tuftool are only on tuftool/tests/, and one commit does have changes on both tuftool and tough (which is required to have successful tests) - I am really not sure how to organize the commits in this case..

[jpculp]

@fghanmi, that's true. It might make the most sense to keep it as one commit despite it crossing over.

[fghanmi]

@fghanmi, that's true. It might make the most sense to keep it as one commit despite it crossing over.

So squashing to 1 commit is okay ?

[jpculp]

@fghanmi, looking closer at the TUF spec, we might need to tweak the approach here. I saw this interesting excerpt from 6.2.1. (This is if we have sha256 AND sha512 at the same time)

if the referrer metadata lists N cryptographic hashes of the referred file, then there MUST be N identical copies of the referred file, where each file will be distinguished only by the value of the digest in its filename. The modified filename need not include the name of the cryptographic hash function used to produce the digest because, on a read, the choice of function follows from the selection of a digest (which includes the name of the cryptographic function) from all digests in the referred file.

[fghanmi]

@jpculp I've added another commit to always consider adding targets/sha512_hash.target_filename
If this change is okay for you, I will squash the commits as agreed.