Digital Signature — Step by Step
Sender → ReceiverAlice writes the message (plaintext)
"You're hired, Bob. Salary: $75,000." — unencrypted, readable text.
Alice hashes the plaintext
A hash function creates a fixed-length message digest. Even one character change = completely different hash.
Alice encrypts the hash with her PRIVATE KEY
This encrypted hash is her digital signature. Only Alice can create this — no one else has her private key.
Alice sends: plaintext + digital signature
The message does NOT need to be encrypted. The signature is attached separately. Bob receives both.
Bob decrypts the signature with Alice's PUBLIC KEY
Alice's public key is available to anyone. Decrypting the signature reveals the original hash Alice created.
Bob hashes the received plaintext independently
Bob runs the same hash function on the message he received to create a fresh hash.
Bob compares the two hashes
Hash from signature = Hash from message? → ✅ Integrity confirmed + Origin verified = Non-repudiation. Mismatch? → ❌ Data was altered or signature is invalid.
Hashing vs. Digital Signature vs. Certificate
| Mechanism | What It Proves | Who Can Verify | Identifies Sender? |
|---|---|---|---|
| Hashing | Data hasn't changed (integrity) | Anyone | ❌ No |
| Digital Signature | Integrity + sender identity | Anyone with public key | ✅ Yes |
| Certificate | Public key belongs to a verified identity | Anyone trusting the CA | ✅ Yes (via CA) |
Key Rules to Remember
Private = Sign
The PRIVATE key creates (signs) the digital signature. Never shared.
Public = Verify
The PUBLIC key verifies the signature. Anyone can have it. Cannot create a signature.
No Encryption Needed
Digital signatures work on plaintext. The message doesn't need to be encrypted for the signature to prove integrity + origin.
Hash ≠ Sender ID
A hash alone only tells you if data changed — NOT who sent it. You need a digital signature for origin proof.