Nonrepudiation, Integrity & Digital Signatures

Contracts in the physical world → cryptographic guarantees in the digital world

Why Nonrepudiation Matters

A foundational goal of cryptography is to ensure that when data is sent to a third party, the recipient can verify both its integrity (unchanged content) and its origin (who sent it). Just like signing a paper contract, digital systems need a way to prove “this really came from the sender.”

Nonrepudiation Combines proof of integrity (data hasn’t changed) with proof of origin (authentic sender), giving high assurance of authenticity.

Proof of Integrity: Hashing

A hash (message digest) is a short, fixed-length “fingerprint” derived from the plaintext. If any bit of the data changes, the hash changes, revealing tampering or corruption.

Key points

  • Easy to compute for any data (files, messages, documents).
  • Small changes in input → vastly different output (“avalanche effect”).
  • Confirms what you received equals what was sent.
  • Does not identify who sent it.
Example workflow: Download a file (e.g., an eBook). Compute its hash locally and compare it to the published hash. If they differ, the file was altered or corrupted in transit.

Integrity Check (Concept)

Original Data Hash(original) Received Data Hash(received) Compare

If both hashes match → integrity verified. If not → data changed.

From Integrity to Origin: Digital Signatures

Hashing verifies integrity, but not who sent the data. To add proof of origin, we use a digital signature, which provides nonrepudiation—the sender cannot credibly deny having sent the message.

How a Digital Signature Works (Alice → Bob)

  1. Hash: Alice hashes the plaintext message (e.g., “You’re hired, Bob.”).
  2. Sign: Alice encrypts that hash with Alice’s private key → this encrypted hash is the signature.
  3. Send: Alice sends plaintext + signature to Bob (email or other channel).
  4. Verify origin: Bob uses Alice’s public key to decrypt the signature, recovering the original hash Alice made.
  5. Verify integrity: Bob independently hashes the received plaintext and compares both hashes.
  6. Match? If they match, the message is unaltered and must have been signed with Alice’s private key → strong proof of origin.

Signature Verification (Sequence)

Alice Bob Hash plaintext Encrypt hash w/ private key Send plaintext + signature Decrypt sig w/ public key Hash received plaintext Compare

Matching hashes ⇒ integrity verified unchanged and origin tied to Alice’s private key ⇒ nonrepudiation.

Practical Notes

Gutenberg File Hash — A Thought Experiment

Imagine downloading Volume 1 of an encyclopedia (about 8.1 MB). You compute its hash and record it. If even a single character in the file is changed later, the size may remain the same, but the new hash will be completely different. Comparing the recorded “original” hash with your computed hash reveals the change immediately.

Next steps when hashes don’t match:
  • Re-download to rule out corruption or tampering.
  • Run a file diff to locate the exact change.

Key Takeaways

Hashing proves integrity. Digital signatures add proof of origin and enable nonrepudiation. Together, they let recipients verify that data is unchanged and truly from the claimed sender.