English is the default.
Cryptography

Digital Signatures: Who Signed These Bytes?

Distinguish verifying a signature from hiding information or proving it is harmless.

Foundational6 min explorationReviewed
My learningNot started

Simple: everyday language, with no technical background needed.

Simple explanation

Understand it

A digital signature binds data to a signing key. Verification uses the corresponding public key to check that the signed bytes match. It is closer to a tamper-evident seal than a lock that hides the letter.

A signed software update can help a device check its publisher and integrity. The device must also trust the signing key. A valid signature is not a promise that the software has no bugs.

Technical explanation

Under the hood

Signature schemes use a private signing key and public verification key. A certificate or another trust mechanism can bind a key to an identity. Validation includes the scheme and relevant trust policy, not just a green check from a mathematical operation.

Practitioner explanation

Practitioner perspective

Protect signing keys, restrict signing workflows and plan for key compromise and revocation. Verification policy may need version or freshness checks because an old validly signed artifact can remain valid cryptographically. Separate confidentiality, identity assurance and integrity claims.

Digital Signatures

A verifier compares a letter seal with a reference motif; the letter itself is not concealed.

A digital signature binds data to a signing key. Verification uses the corresponding public key to check that the signed bytes match. It is closer to a tamper-evident seal than a lock that hides the letter.

Illustrated analogy · Select the image to enlarge
See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

Check a signature before trusting a message.

Example: verify a signed software release. A signature checks integrity and the signing key, not whether software is safe.

Steps1. Message and signature 2. Signature verifies
Click a box or choose its name to learn what it means.
YouReadyCheck ortransformReadyResultReadyYouReadyCheck ortransformReadyResultReady
Ready to traceVerification succeeds
Before you start · 2 steps

Verification succeeds

The verifier needs an authentic public key associated with the intended signer.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • You

    The person making the decision in this fictional example.

    Example: You decide whether to share information, approve a request or check it first.

  • Check or transform

    Digital-signature verification using the message, signature and an authentic public key.

    Example: Check a signed release without assuming a valid signature makes the software harmless.

  • Result

    The outcome produced by the operation in this example.

    Example: Read the current state and the step explanation to see what succeeded or failed.

Verification succeeds

The verifier needs an authentic public key associated with the intended signer.

  1. You Check or transform: Message and signature. The verifier receives the release and its digital signature and uses the trusted public key.
  2. Check or transform Result: Signature verifies. Verification succeeds for these bytes and this key. The signature alone does not prove the content is safe or true.

Message altered

Changing signed content causes verification to fail in this example.

  1. You Check or transform: Changed message. The verifier receives modified bytes alongside the original signature.
  2. Check or transform Result: Verification fails. The signature does not verify against the modified message. Stop and investigate the source.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Publisher

The publisher signs the intended artifact.

1 / 3
Read every step without animation

Verified artifact

  1. Publisher. The publisher signs the intended artifact.
  2. Verification. The recipient checks with a trusted public key.
  3. Policy. The recipient also checks the expected version.

Integrity and release policy work together.

Changed artifact

  1. Signed bytes. An artifact has a publisher signature.
  2. Bytes changed. The artifact is modified after signing.
  3. Check fails. The signature no longer verifies for those bytes.

Do not bypass a failed verification check.

Attack view

A validly signed but obsolete software package is presented as the newest release.

Defender view

  • Verify the signature and the expected publisher through a trusted mechanism.
  • Check version and freshness requirements as well as the signature.

Common mistakes

  • A signature does not encrypt the document.
  • Validly signed software may still contain vulnerabilities.

Check your understanding

What does a digital signature not provide by itself?
Active recall: explain this idea in 30 seconds

A digital signature binds data to a signing key. Verification uses the corresponding public key to check that the signed bytes match. It is closer to a tamper-evident seal than a lock that hides the letter.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Technology fundamentals

Back to topic