Keys, encryption, and signatures

Ava's application receives a message saying that she signed in. Anyone could write those words. The application needs a way to check where the message came from and whether someone changed it.

Cryptography supplies those checks. Its algorithms are precise, published recipes for a calculation, so anyone can run them and get the same answer. What keeps the result protected is a cryptographic key, a value used by an algorithm to perform a protected operation. Keys must be generated and handled carefully; a memorable phrase or a value that merely looks random is not a suitable replacement. Different operations need different kinds of keys.

Words alone×

"Ava signed in."

Where it came from

Anyone could write those words

Whether someone changed it

No way to check

Needs evidence, not just words

With a key×

"Ava signed in." + a cryptographic check

Where it came from

Checked

Whether someone changed it

Checked

The key keeps the result protected

The algorithm is a published recipe anyone can run. A memorable phrase or a value that merely looks random is not a suitable replacement for a key.

With symmetric cryptography, the participants share a secret key. An encryption scheme can use that key to protect a message and recover its contents. Anyone who obtains the key may be able to do the same, so distributing and protecting it is part of the design.

With asymmetric cryptography, there is a mathematically related key pair: a private key that must stay private and a public key that can be shared. The algorithm determines what the pair can do. A signing key pair is not automatically an encryption key pair.

This gives a sign-in provider a useful arrangement. It can keep the signing key private while applications use the corresponding public key to verify its messages.

Symmetric×

Shared secret key

Keys

One secret key

Who holds it

The participants share it

What it allows

Protect a message and recover its contents

Anyone who obtains the key may be able to do the same.

Asymmetric×

Key pair

Keys

A private key and a public key

Who holds it

Provider: the private key. Applications: the public key.

What it allows

The private key signs; the public key verifies

Checking a message does not give the ability to sign new ones.

A signing key pair is not automatically an encryption key pair.

Suppose someone intercepts a message while it travels between Ava's browser and a server. Encryption protects its confidentiality: without the required key, the observer should not be able to recover the readable original, the plaintext, from the scrambled result, the ciphertext.

Modern authenticated encryption also detects changes to protected data. Protecting integrity means making sure data hasn't been changed, and encryption alone should not be assumed to provide every integrity guarantee. The protocol and algorithm matter.

HTTPS uses TLS to protect the connection. That does not mean every message remains encrypted after the receiving application opens it, stores it, or passes it elsewhere. Always ask which part of the journey a protection covers.

1Sender×

Encrypt

Contents

Readable plaintext

Key

Used to encrypt

2In transit×

Intercepted

Contents

Ciphertext

Key

The observer lacks it

• Cannot recover the plaintext
• Authenticated encryption also detects changes

3Recipient×

Decrypt

Contents

Readable plaintext

Key

Used to decrypt

That does not mean every message remains encrypted after the receiving application opens it, stores it, or passes it elsewhere.

A digital signature answers a different question. The provider signs data with a private key. An application verifies the signature with the public key and can detect changes to the signed data.

A signature does not hide the contents. Ava's sign-in message may be readable while still being signed. Nor does a valid signature make every claim true: it establishes that the corresponding private key signed the protected data.

The application must already have a trustworthy way to associate that public key with the expected provider. Verifying with a key supplied by an attacker would only establish that the attacker signed the message.

Providers commonly publish their current public keys as a key set at a fixed address on their own HTTPS host, so an application fetches them over a connection protected for the provider's name. Each key carries a key ID, and a signed message usually names the ID of the key that signed it. That lets a provider introduce a new key alongside the old one without confusing anyone checking its messages.

Provider key×

Signed by the provider

Signed with

The provider's private key

Data

Unchanged

Verified with

The provider's public key

Valid: the corresponding private key signed the data.

Altered data×

Changed after signing

Signed with

The provider's private key

Data

Changed

Verified with

The provider's public key

Reject altered data.

Attacker key×

A key supplied by an attacker

Signed with

The attacker's private key

Data

Written by the attacker

Verified with

A key supplied by an attacker

Would only establish that the attacker signed the message.

A signature does not hide the contents. Nor does a valid signature make every claim true.

A hash function turns input into a fixed-length digest. It is designed so that recovering the original input or finding different input with a chosen digest is practically impossible for a suitable cryptographic hash. Unlike encryption, hashing has no decryption key.

Hashes help detect changes, but a digest sent beside a message is not proof of its source. Someone who can replace both can calculate a new digest. A signature or another authenticated mechanism is needed to establish that trust.

Signatures use hashes too. A signature algorithm such as RS256 or ES256 first hashes the data with SHA-256, a widely used hash function, and then signs that short digest. The two names differ in the kind of key pair they use.

Password storage adds another requirement: passwords are often guessable. A fast general-purpose hash lets an attacker test guesses quickly. Password storage needs a purpose-built, costly password hashing scheme and a unique salt: a random value stored with each password and mixed into its hash, so that two accounts with the same password don't end up with the same stored value.

Bare digest×

Message + digest

Message + digestAn attacker replaces bothReplacement message + new digestHash and compare

Defeats that unauthenticated comparison

Signature×

Message + signature

Message + signatureAn attacker replaces bothReplacement message + a signature from another keyVerify with the provider's public key

Detects the change

A hash helps detect changes, but a digest sent beside a message is not proof of its source.

Computers hold everything, text included, as bytes: numbers from 0 to 255. Keys, digests and signatures are bytes that don't correspond to printable characters, and systems built to carry text can damage them. An encoding changes how data is represented so that another system can carry or read it. Base64 writes any bytes using 64 safe characters: letters, digits, + and /. Base64url swaps those two symbols for - and _, so the result can sit in a URL. Base64 may also add = at the end to fill out the last group of characters; base64url usually leaves it off. Anyone with the encoded value can reverse the transformation; there is no secret key.

This matters when a token looks unreadable at first glance. It may only be encoded. A common token format, the JSON Web Token or JWT, joins three base64url parts with dots: a header naming the signature algorithm and key ID, a payload holding the claims as JSON, and the signature. Decoding the first two parts reveals the claims without proving that the token is authentic or acceptable.

Base64×

Readable text: Ava

Encoded text

QXZh

Base64

Letters, digits, + and /

Base64url

Swaps those two symbols for - and _

Reversing it

Anyone with the encoded value

There is no secret key.

JWT×

A JWT joins three base64url parts with dots

Header

The signature algorithm and key ID

Payload

The claims as JSON

Signature

The third part

• Decoding reveals the claims
• Proving that the token is authentic or acceptable

Follow Ava's sign-in message again. Encoding may make it convenient to transport. A signature can let the application verify who signed it and whether it changed. TLS protects the connection carrying it. If the message itself needs confidentiality beyond that connection, it needs an appropriate encryption design.