Hashing - DSA | Digital Signatures and Authentication Workflows

This chapter explores the fundamental mechanics of digital signatures and authentication workflows within asymmetric cryptography. Through a practical transaction scenario, we analyze why simple encryption is insufficient for verifying a sender's identity and demonstrate how combining private and public keys provides both confidentiality and non-repudiation.

1. The Core Problem: Trust and Identity in Digital Communication

In basic cryptography, encryption is often equated with security. However, security consists of multiple distinct pillars:

• Confidentiality: Ensuring that unauthorized third parties cannot read the contents of a message.
• Authenticity (Identity Verification): Ensuring that the message actually originated from the claimed sender.
• Integrity: Ensuring the message was not altered in transit.
• Non-Repudiation: Ensuring the sender cannot deny having sent the message.

While encrypting a message with a recipient's public key guarantees confidentiality (only the recipient can decrypt it), it does absolutely nothing to guarantee authenticity. Because public keys are open and accessible to everyone, any malicious actor can encrypt a fraudulent message, send it to the recipient, and claim to be someone else.

Without a mechanism to verify the sender's identity, secure digital transactions and communication systems would collapse under the threat of impersonation.

2. The Ram-Shyam-Mohan Analogy

To understand this vulnerability and its resolution, the lecture introduces a classic three-party financial scenario:

The Characters & Their Roles

1. Ram (The Account Owner): Owns money but has deposited it with Shyam for safekeeping. Ram has a public-private key pair: $(\text{PU}_{\text{Ram}}, \text{PR}_{\text{Ram}})$.
2. Shyam (The Custodian/Banker): Holds Ram's money and executes transactions based on Ram's instructions. Shyam has a public-private key pair: $(\text{PU}_{\text{Shyam}}, \text{PR}_{\text{Shyam}})$.
3. Mohan (The Third Party / Potential Attacker): A malicious actor who wants to divert Ram's money to his own account. Mohan has his own key pair and has access to everyone's public keys.

The Objective

Ram wants to send a secure message to Shyam saying: "Send 100 Rupees to Mohan."

Because the message travels over the public internet, it must be protected against eavesdropping and tampering. More importantly, Shyam must be absolutely certain that the instruction came from Ram and not from Mohan trying to steal Ram's funds.

3. The Naive Approach (Confidentiality Without Authentication)

In a naive implementation, Ram attempts to secure the transaction by focusing solely on confidentiality. He encrypts the message using Shyam's public key.

The Encryption Flow (Naive)

Ram's Message (X): "Send 100 Rupees to Mohan"
       |
       | Encrypted using Shyam's Public Key (PU_Shyam)
       v
Ciphertext (Y)
       |
       | Sent over the Internet
       v
Shyam receives Ciphertext (Y)
       |
       | Decrypted using Shyam's Private Key (PR_Shyam)
       v
Decrypted Message (X): "Send 100 Rupees to Mohan"

Why This Seems Secure

• Only Shyam possesses the private key ($\text{PR}_{\text{Shyam}}$) required to decrypt $Y$ back into $X$.
• An eavesdropper on the network cannot read the transaction details.

4. The Vulnerability: How Mohan Exploits the Naive System

The critical flaw in the naive approach is that anyone can encrypt a message using Shyam's public key because it is publicly available. Mohan can exploit this to execute an impersonation attack.

The Attack Workflow

Mohan generates Fake Message (X_fake): "I am Ram. Send 1000 Rupees to Mohan."
       |
       | Encrypted using Shyam's Public Key (PU_Shyam) 
       | (Note: Mohan has access to PU_Shyam because it is public!)
       v
Fake Ciphertext (Y_fake)
       |
       | Sent to Shyam, pretending to be Ram
       v
Shyam receives Fake Ciphertext (Y_fake)
       |
       | Decrypted using Shyam's Private Key (PR_Shyam)
       v
Decrypted Message: "I am Ram. Send 1000 Rupees to Mohan."

The Consequences

1. Successful Fraud: Shyam decrypts the message successfully. Because it was encrypted with his public key, he assumes it is a legitimate, secure message. He transfers 1,000 Rupees to Mohan.
2. Repudiation Dispute: In the future, Ram reviews his balance and asks, "Why did you transfer 1,000 Rupees to Mohan? I never authorized this!" Shyam replies, "But I received an encrypted message that decrypted perfectly!"
3. System Failure: There is no cryptographic proof to determine whether Ram or Mohan generated the message.

5. The Solution: Introducing Digital Signatures

To solve this problem, Ram must leave a unique, unforgeable "stamp" or "signature" on the message. This signature must prove that the message could only have been generated by someone in possession of Ram's private key ($\text{PR}_{\text{Ram}}$).

In asymmetric cryptography, the key properties are mathematically linked such that:

• A message encrypted with a Public Key can only be decrypted by the corresponding Private Key (Confidentiality).
• Conversely, a message encrypted with a Private Key can only be decrypted by the corresponding Public Key (Authentication/Signature).

Because Ram is the only person in the world who possesses $\text{PR}_{\text{Ram}}$, if a message can be successfully decrypted using Ram's public key ($\text{PU}_{\text{Ram}}$), it serves as absolute proof that Ram was the one who encrypted it.

6. Step-by-Step Cryptographic Workflow (Encryption & Signing)

To achieve both confidentiality and authenticity, the message must undergo a double-encryption process.

Note: In standard modern production environments, we typically generate a cryptographic hash of the message, encrypt the hash with the sender's private key to create a "digital signature," and append it to the plaintext (or encrypted plaintext).

To keep the core concept highly intuitive, the lecture explains this via a direct double-encryption pipeline where the message itself is transformed sequentially. Both approaches rely on the exact same underlying mathematical trust assumptions.

The Sender's Pipeline (Ram's Side)

Ram starts with the plaintext message $X$: "Send 100 Rupees to Mohan."

Plaintext Message (X)
       |
       | Step 1: Encrypt with Shyam's Public Key (PU_Shyam)
       | [Guarantees Confidentiality]
       v
Intermediate Ciphertext (Y)
       |
       | Step 2: Encrypt with Ram's Private Key (PR_Ram)
       | [Guarantees Authenticity / Digital Signature]
       v
Final Secure Payload (Z)

• Why Step 1 is done: By encrypting with $\text{PU}_{\text{Shyam}}$, Ram ensures that only Shyam can read the final decrypted content.
• Why Step 2 is done: By encrypting the result with $\text{PR}_{\text{Ram}}$, Ram signs the message. This creates the final payload $Z$, which can only be unwrapped by someone using Ram's public key ($\text{PU}_{\text{Ram}}$).

7. Step-by-Step Verification Workflow (Decryption & Authentication)

When Shyam receives the payload $Z$, he must reverse the double-encryption process in the exact opposite order.

The Recipient's Pipeline (Shyam's Side)

Received Payload (Z)
       |
       | Step 1: Decrypt using Ram's Public Key (PU_Ram)
       v
Intermediate Ciphertext (Y)
       |
       | Step 2: Decrypt using Shyam's Private Key (PR_Shyam)
       v
Original Plaintext Message (X): "Send 100 Rupees to Mohan"

Detailed Verification Mechanics:

1. Unwrapping the Signature: Shyam applies Ram's public key ($\text{PU}_{\text{Ram}}$) to $Z$.
   • If this step succeeds and yields a structured ciphertext $Y$, it proves mathematically that the payload $Z$ was created using Ram's private key ($\text{PR}_{\text{Ram}}$).
   • Authenticity is verified.
2. Unwrapping the Confidentiality Layer: Shyam applies his own private key ($\text{PR}_{\text{Shyam}}$) to $Y$.
   • This decrypts the intermediate ciphertext into the readable plaintext message $X$.
   • Confidentiality is preserved because no one else could have performed this step.

8. Why the Attack Fails Under the New Paradigm

Let's analyze what happens if Mohan tries to execute his fraud under this secure double-encryption workflow.

Scenario A: Mohan tries to generate a fake payload $Z$

1. Mohan writes the fake message: "Send 1000 Rupees to Mohan."
2. He encrypts it with Shyam's public key ($\text{PU}_{\text{Shyam}}$) to get a fake intermediate ciphertext $Y_{\text{fake}}$.
3. To complete the protocol and generate the final payload $Z$, Mohan must encrypt $Y_{\text{fake}}$ with Ram's Private Key ($\text{PR}_{\text{Ram}}$).
4. The Roadblock: Mohan does not have access to $\text{PR}_{\text{Ram}}$. Private keys are kept strictly secret and never shared.

Scenario B: Mohan tries to bypass Ram's key by using his own private key

1. Mohan decides to encrypt $Y_{\text{fake}}$ using his own private key ($\text{PR}_{\text{Mohan}}$) to produce a payload $Z_{\text{forged}}$.
2. He sends $Z_{\text{forged}}$ to Shyam, claiming it is from Ram.
3. Shyam receives $Z_{\text{forged}}$ and attempts to decrypt it using Ram's Public Key ($\text{PU}_{\text{Ram}}$) (since the message claims to be from Ram).
4. The Failure: Because $Z_{\text{forged}}$ was encrypted with $\text{PR}_{\text{Mohan}}$ and not $\text{PR}_{\text{Ram}}$, the decryption using $\text{PU}_{\text{Ram}}$ fails completely. It outputs corrupted, unreadable garbage data.
5. Shyam immediately detects the fraud, rejects the transaction, and the attack is thwarted.

9. Key Cryptographic Concepts Compared

10. Summary and Key Takeaways

• The Identity Deficit: Standard asymmetric encryption using only the recipient's public key ensures confidentiality but completely fails to verify the sender's identity.
• Public Key Accessibility: Because public keys are open to everyone, any malicious actor (like Mohan) can encrypt a message and falsely claim to be another user (like Ram).
• The Power of Private Keys: A digital signature relies on the premise that a private key is strictly confidential to its owner. Encrypting data with a private key acts as an unforgeable digital stamp.
• Double-Encryption Pipeline: By combining both key pairs, a sender can guarantee both privacy and identity. The sender encrypts with the recipient's public key (for privacy) and then encrypts with their own private key (for identity).
• Order of Decryption: The recipient must decrypt the outer layer using the sender's public key first (verifying identity) before decrypting the inner layer with their own private key (reading the content).
• Cryptographic Prevention of Fraud: If an attacker attempts to forge a message, they must either obtain the sender's private key (which is impossible if kept secure) or use their own private key, which will cause the recipient's decryption process to fail and expose the tampering.