Ref: https://learn.cantrill.io/courses/2022818/lectures/45637121

YouTube: https://www.youtube.com/watch?v=BkKFJ1yZRgI

• Summary:
• Contents:

PKI Refresher

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0400-TECH_FUNDAMENTALS/00_LEARNINGAIDS/TF-GEN-DigitalSignatures-1.png

• Private key → kept safe & secret, can decrypt ciphertext from public key, and can also sign something which public key can then verify it was indeed signed with private key
• Public key → public, shared widely, can encrypt anything that can then only be decrypted by private key, can also verify that a signature comes from private key
• ‼️ Encryption ≠ Signing!! (even though they both use PKI)

Digital Signing - Architecture

Diagram: https://github.com/acantril/aws-sa-associate-saac03/blob/main/0400-TECH_FUNDAMENTALS/00_LEARNINGAIDS/TF-GEN-DigitalSignatures-2.png

• 🔧 Together with hashing, digital signing verifies integrity (WHAT) & authenticity (WHO)
  • 💡 Can download data from Netflix, and know the data hasn't been altered, and that it comes from Netflix
    • Nobody can alter Netflix data without it being obvious, and nobody can get away by creating data & claiming it's from Netflix
• ‼️ Layered on top of normal usage!
  • Clients can ignore integrity & authenticity if desired or not supported
• Process for creating digitally signed data:
  1. Generate hash of document/data
  2. Author signs hash with their private key → digital signature (encrypted hash)
  3. 🔧 Document + Signed Hash (Signature) = Digitally signed data
  • ❗ Wouldn't it make more sense to sign the whole document? NO! → Document can be very big, but its hash is small → Much easier computationally to sign the small hash
  • 💡 Wouldn't it make more sense for author to encrypt the whole document? NOT NECESSARILY! Encryption is only needed when you want to protect the data from public viewing, otherwise it's wasteful computation! If author doesn't mind their document being publicly available and only wants to prove that the document is unaltered and from them, author only needs to sign the document, not encrypt it!
• Process for verifying digitally signed data:
  1. Client downloads digitally signed data
  2. Client uses author's public key to decrypt signature → gets author's original hash
     • Author's original hash represents state of document when author uploaded it
  3. Client generates a hash of document
     • If generated hash matches original hash → 🎉 document authenticity and integrity verified (document is from author, and hasn't been altered)
     • If hashes don't match → can't trust document!
  • 💡 Remember: this process is optional → client could just download document and not verify anything… but they could be vulnerable to malicious exploits then!
• ❗ Whole architecture relies on trusting author's public key
  • Chain of trust: trust public key → trust private key → trust entity → trust data
  • ‼️ The wider the distribution of author's public key, the easier it is to spot if it has been modified somewhere!!
    • 💡 e.g. Bob uploads his public key to his website, Twitter, LinkedIn… → if all public keys match, we can trust it. If one is faulty, we can well suspect that it was changed in its location (odd public key vs the rest)
• If extra security is needed (e.g. protect document from anyone except one client), author can encrypt digitally signed data with client's public key and send it to them