A project team publishes the SHA-256 hash of each signed-off contract and claims this proves which partner sent each document. What should the cloud security professional point out?
Select an answer to reveal the explanation.
Short Explanation
A hash tells you the document hasn't changed, but it can't tell you who wrote it; anyone can hash anything. For 'they can't deny sending it,' you need a digital signature made with a private key only they hold. Watch the shared-key trap: if both sides hold the key, either one could've made it.
Full Explanation
Non-repudiation means the originator cannot credibly deny having created or sent a message. A cryptographic hash provides integrity: it shows whether data matches a reference value. Because hash functions are public and require no secret, anyone can compute the hash of any document, so a hash alone says nothing about who produced it. A digital signature provides non-repudiation by having the sender sign the document's hash with a private key that only they control, while others verify it with the corresponding public key, usually bound to the sender's identity through a certificate. Moving to a longer digest such as SHA-512 increases collision resistance but still involves no secret and therefore no identity. TLS protects the channel and authenticates the endpoints of that session, but it does not produce a durable, verifiable signature on the document that a third party can check later. Encrypting the hash with a symmetric key shared by both partners produces a message authentication code, which shows the message came from someone holding the key; since both partners hold it, either could have created it, so it does not provide non-repudiation. Exam caveat: the outline pairs hashing with integrity and non-repudiation, but non-repudiation depends on signing. Operational check: verify that contracts carry signatures validated against trusted certificates.