Video summary

Non-repudiation - CompTIA Security+ SY0-701 - 1.2

Main summary

Key takeaways

Educational

Main Ideas and Concepts

  • Cryptographic foundation: non-repudiation

    • Goal: ensure that when someone sends data to a third party, the third party can verify the information really came from the sender.
    • Analogy: a signed contract—if inspected later, its signature can reasonably prove it was signed by the person.

  • Two related assurances in cryptography

    1. Proof of integrity
      • The receiver can verify that the data received is exactly the same as the data originally sent.
      • Ensures accuracy/consistency and detects any changes to the contents.
    2. Proof of origin (also framed as authentication)
      • The receiver can verify who sent the data.
      • Often implemented using digital signatures to support non-repudiation.

  • Hashing for proof of integrity

    • A hash is a short string derived from the data in the plaintext (often called:
      • message digest
      • fingerprint).
    • Property: any change to the data results in a different hash.
    • Limitation: hashing alone verifies integrity, but does not prove which individual sent the data.

Methodology / Step-by-Step Processes

A) Proof of Integrity Using Hashing (Practical Example)

  1. Obtain the original data
    • Example: Project Gutenberg “Gutenberg encyclopedia”, volume one (8.1 MB).
  2. Run the data through a hashing function to create a hash/fingerprint of the original file.
  3. Change one character anywhere in the file (while keeping file size the same).
  4. Re-hash the modified file.
  5. Compare hashes:
    • If hashes differ → data was modified/corrupted.
  6. Optional follow-up (if an issue is suspected):
    • download again, or
    • perform a diff/comparison to locate exactly where differences occurred.

B) Digital Signature Process (Alice to Bob) for Proof of Origin + Non-Repudiation

Characters

  • Alice = sender
  • Bob = receiver

Steps

  1. Alice prepares the message
    • Example: “you’re hired Bob”.
  2. Alice creates a hash of the plaintext message using a hashing algorithm.
  3. Alice encrypts the hash using her private key.
  4. Alice sends Bob:
    • the plaintext message, and
    • the digital signature (the encrypted hash).
  5. Bob receives the message and signature.
  6. Bob uses Alice’s public key to decrypt/verify the digital signature.
    • This recovers the original hash that Alice created.
  7. Bob independently computes a new hash:
    • run the received plaintext through the same hashing algorithm.
  8. Bob compares:
    • the hash recovered from the signature vs.
    • the hash Bob computed from the received plaintext.

Result if hashes match:

  • integrity is confirmed (data wasn’t altered), and
  • origin is confirmed (it must have been signed by Alice, since only she has the private key).

Operational Note

  • In real life, much of this occurs automatically behind the scenes when a user clicks something like “Add digital signature”.

Overall Lesson

  • Integrity is proven with hashes (detects content changes).
  • Origin/non-repudiation is achieved with digital signatures (private key signing + public key verification).
  • This enables third parties to later validate that the sender was authentic and that the transmitted data remained unaltered.

Speakers / Sources

  • Speakers: Not explicitly identified (narrator/instructor only).
  • Sources referenced in the content:
    • Project Gutenberg (as the example provider of the encyclopedia volume used to demonstrate hashing).

Original video