Article
Card image cap for article

Electronic Signatures: Authenticity and Integrity in Practice (with OpenSSL Examples)

Open this select menu

12/27/2025

Opening

Electronic signatures are widely used in everyday business workflows, yet their security properties are sometimes unclear: a “digital” signature is intuitively equated with encryption and secrecy, but that is not what a true cryptographic signature guarantees.

At its core, a digital or (advanced) electronic signature is about authenticity and integrity, not confidentiality.

What a Digital Signature Really Is

In cryptography, a digital signature is a mathematical scheme that lets a verifier check two things:

  • Authenticity – the message originates from the holder of a specific private key
  • Integrity – the message has not been altered since it was signed

A signer holds a private key, acting as the Sender. The corresponding public key is shared with the verifier, who acts as the Recipient of a message from the signer.

When the signer produces a signature for a given message, anyone with the public key can verify that signature, but no one without the private key can forge a valid one (under realistic assumptions).

High‑Level Signing Workflow

A typical digital signature workflow looks like this:

  1. The Sender chooses a message M (e.g. a PDF such as an NDA, or a text file)
  2. The Sender computes a hash of the message using a cryptographic hash function H (such as SHA‑256)
  3. The Sender uses the private key and a signature algorithm to sign this hash, producing a signature σ
  4. The Sender transmits both M and σ to the Recipient
  5. The Recipient recomputes the hash H(M) and verifies σ using the Sender’s public key. If verification succeeds, the message is accepted as authentic and unmodified.

The hash function is one‑way and collision‑resistant: it is computationally infeasible to reconstruct M from H(M) or to find a different message with the same hash. It serves as a compact fingerprint that the signature protects.

Importantly, nothing in this process hides the content of the message. The message can be completely public, yet still cryptographically signed.

OpenSSL Walkthrough: Signing “Hello World”

To make this concrete, I created a simple lab setup on a local machine using OpenSSL and RSA keys. The goal is not production‑grade PKI, but an experiment that shows integrity and authenticity in a realistic setup.

According to the schematic drawing above, I am the Sender who has prepared an NDA document named "nda.txt". My business partner, who is the Receiver, wants not only to review the content of the NDA, but also wants to ensure

  1. Authenticity: the message originates from me, who owns a specific private key
  2. Integrity: the message has not been altered since it was electronically signed
1. Generate an RSA key pair

These are the steps in a command-line interface (bash) that the Sender and Receiver perform. Starting with the Sender, who prepares a private/public key pair:

private key openssl genrsa -out private-key.pem 3072 # public key openssl rsa -in private-key.pem -pubout -out public-key.pem

This gives me, the Sender, a private key for signing (private-key.pem) and a public key for verification at the Receiver's end (public-key.pem)

2. Create a message file

For the sake of illustration, I create a simple text file representing the NDA:

echo -n "NDA between Company A and B" > nda.txt

3. Sign the message (hash + sign)

As Sender, I create a hash of the document nda.txt and sign it with the SHA-256 algorithm:

openssl dgst -sha256 -sign private-key.pem -out nda.sig nda.txt

  • -sha256 hashes the file with SHA‑256
  • -sign uses my private key to sign that hash, producing a binary signature nda.sig

For a readable form:

openssl base64 -in nda.sig -out nda.sig.b64

Now my “electronic signature package” comprises:

  • nda.txt – the plaintext message
  • nda.sig – the signature over the SHA‑256 digest
4. Verify the signature

Now let's transition into the position of the Receiver, who reviews the NDA as plaintext and wants to verify the authenticity of the Sender and integrity of the NDA document. The Receiver uses the public key of the Sender to accomplish this verification:

openssl dgst -sha256 -verify public-key.pem -signature nda.sig nda.txt Verified Ok

If everything matches, OpenSSL prints Verified OK, as depicted in the screenshot above.

That single line tells the Receiver:

  • The file is exactly the file that was signed (integrity)
  • It was signed by the holder of the private key corresponding to public-key.pem (authenticity)

Note: this assumes that the Receiver already trusts that the public key belongs to the claimed signer (me as Sender). Normally a Certificate Authority (CA) is the entity establishing this trust by supplying an X.509 certificate to the applicant of a private/public key.

Why There is No Confidentiality Here

Notice what was sent in the example: the recipient receives the plaintext nda.txt and a separate nda.sig. Anyone who intercepts the transmission can read “NDA between Company A and B” from nda.txt without breaking any cryptography.

The hash and signature are not hiding the content. They are only protecting it from undetected modification and proving its origin.

Confidentiality is achieved with encryption, not with signatures:

  • For confidentiality, I would encrypt the message (often with a symmetric key that is itself protected with the recipient’s public key).
  • For authenticity and integrity, I would sign the document (or a hash of it) with my private key (as explained above)

Note: real‑world protocols often combine both: “sign‑then‑encrypt” or “encrypt‑then‑sign”, depending on the design. But conceptually, these are two orthogonal properties.

Where Electronic Signatures Fit Legally

Legal frameworks such as the EU’s eIDAS regulation distinguishes different levels of electronic signatures, but the cryptographic core is always about ensuring that a document:

  • is tied to a specific signer (authenticity), and
  • has not been altered since signing (integrity)

Qualified or advanced electronic signatures add identity verification (via trusted service providers and certificates), audit trails, and sometimes hardware security modules. The underlying math, however, still implements the same integrity and authenticity guarantees illustrated by the simple OpenSSL example.

Summary

When we talk about “electronic signatures”, it is important to understand what cryptography actually achieves. The cryptographic signature gives integrity and authenticity.

Confidentiality requires separate encryption.

Understanding this difference helps architects, developers, and business stakeholders comprehend and communicate correctly about what their systems actually guarantee, and what they still need to add.

Go back