A digital signature doesn’t prove who signed something; it proves that the content hasn’t changed since it was signed by someone.

Imagine you receive a document and a signature. You want to be sure two things:

  1. The document hasn’t been tampered with since it was signed.
  2. The signature is genuinely associated with that specific document.

Here’s a simplified look at how that works, using OpenSSL for demonstration. We’ll create a text file, sign it, and then verify the signature.

Step 1: Create a Document

Let’s make a simple text file.

echo "This is the confidential message." > message.txt

Step 2: Generate a Private and Public Key Pair

Digital signatures rely on asymmetric cryptography. You have a private key (kept secret) to sign and a public key (shared) to verify.

openssl genrsa -out private.pem 2048
openssl rsa -pubout -in private.pem -out public.pem
  • genrsa -out private.pem 2048: This command generates a 2048-bit RSA private key and saves it to private.pem. The length (2048 bits) is a common security standard.
  • rsa -pubout -in private.pem -out public.pem: This extracts the public key from the private.pem file and saves it to public.pem.

Step 3: Sign the Document

Now, we’ll create a signature for our message.txt using the private key. A common method is to first hash the document and then encrypt that hash with the private key.

openssl dgst -sha256 -sign private.pem -out message.sig message.txt
  • dgst -sha256: Specifies the SHA-256 hashing algorithm. This creates a unique, fixed-size fingerprint of the message.txt.
  • -sign private.pem: Tells openssl to use private.pem for signing.
  • -out message.sig: The output file for the signature.
  • message.txt: The input file to be signed.

At this point, message.sig contains the encrypted hash of message.txt. It’s the digital signature.

Step 4: Verify the Signature

To verify, we need the original document (message.txt), the signature (message.sig), and the signer’s public key (public.pem).

openssl dgst -sha256 -verify public.pem -signature message.sig message.txt
  • dgst -sha256: Again, specifies SHA-256.
  • -verify public.pem: Tells openssl to use public.pem for verification.
  • -signature message.sig: The signature file to check.
  • message.txt: The original document.

If the output is Verified OK, the signature is valid. This means:

  1. The message.txt file has not been altered since it was signed.
  2. The signature was created using the private key corresponding to the public.pem you provided.

How it Works Under the Hood: The Decryption and Hash Comparison

When you run the verification command, openssl does two main things:

  1. Decrypts the Signature: It takes message.sig and uses the public.pem to decrypt it. Because of how asymmetric encryption works, only the corresponding public key can "undo" what the private key did during signing. This decryption process yields the original hash that the signer computed from message.txt.
  2. Hashes the Document: It independently calculates the SHA-256 hash of the message.txt file you provided.
  3. Compares Hashes: Finally, it compares the hash obtained from decrypting the signature with the hash it just computed from message.txt.

If these two hashes are identical, the verification succeeds. If even a single bit in message.txt were changed, the hash computed in step 2 would be different from the decrypted hash from step 1, and the verification would fail.

The one thing most people don’t realize is that the signature itself isn’t directly tied to identity. It’s tied to a key pair. To know who signed it, you need an external trust mechanism (like a certificate authority) that vouches for the fact that a specific individual or entity controls a particular public key. Without that, you only know that someone with the matching private key signed it.

The next step is understanding how these public keys are managed and trusted in the real world, which leads to Public Key Infrastructure (PKI) and certificates.

Want structured learning?

Take the full Cryptography course →