Cryptography Fundamentals

Cryptography protects information by transforming it with algorithms and keys. It can keep data confidential, reveal unauthorized changes, authenticate a source, and support digital signatures.

Cryptography does not decide who should have access. It enforces selected security properties after a system defines identities, permissions, data flows, and trust boundaries.

The central mental model

Think in four layers:

Security property: Decide whether you need confidentiality, integrity, authentication, or a combination.
Cryptographic construction: Choose a reviewed construction that provides those properties.
Key and parameter management: Generate, distribute, store, rotate, revoke, and destroy sensitive material correctly.
Protocol and implementation: Combine the pieces without breaking their assumptions.

A strong algorithm cannot rescue a reused nonce, an exposed key, or a protocol that authenticates the wrong party.

Core purposes

Confidentiality

Encryption turns plaintext into ciphertext. Decryption reverses that transformation for someone who has the required key.

Encryption alone does not necessarily detect tampering. Modern systems commonly use authenticated encryption, which protects confidentiality and detects unauthorized changes.

Integrity and message authentication

A cryptographic hash function maps a message to a fixed-length digest. You can compare digests to detect a change, but an unkeyed digest does not prove who created the message.

A message authentication code uses a secret key to authenticate data and detect changes. Every verifier who holds that shared key can also create a valid code.

Digital signatures

A digital signature uses a private key to sign and a public key to verify. It can detect unauthorized modification and authenticate the claimed signer when the public key is trusted.

Signature verification does not establish trust in a public key by itself. Certificates, pinned keys, or another trusted distribution process must connect that key to an identity.

Two key models

Symmetric cryptography

Symmetric cryptography uses secret keying material shared by the participating parties. AES is a standardized symmetric block cipher. Real systems use a defined mode or authenticated-encryption construction around a block cipher.

Symmetric operations suit high-volume data protection. The hard part is sharing and protecting the secret key.

Asymmetric cryptography

Asymmetric cryptography uses related public and private keys. Common purposes include digital signatures and key establishment.

The public key may be distributed. The private key must remain controlled by its owner. Asymmetric operations do not remove the need for symmetric cryptography. Protocols such as TLS use a handshake to authenticate parties and establish keying material, then protect application traffic with symmetric authenticated encryption.

Randomness, nonces, and salts

Cryptographic systems need high-quality random bits for keys and other security-sensitive values. Use a cryptographically secure random-bit generator supplied by a reviewed platform or library.

A nonce is a value that a construction requires to be unique or unpredictable for a particular use. The exact requirement belongs to that construction. Reusing a nonce where uniqueness is required can destroy security.

A salt is public, per-instance data used with some derivation processes, such as password hashing. It is not a substitute for a secret key.

Where cryptography appears

TLS protects client and server traffic against eavesdropping, tampering, and message forgery.
Storage encryption limits disclosure when protected storage is accessed outside its intended controls.
Digital signatures protect software updates, documents, and protocol messages.
Message authentication codes protect messages shared between parties that hold the same secret.
Hash functions support change detection and serve as components inside signatures and other constructions.

Limits you must keep visible

Cryptography protects data, not an entire system.

An authorized endpoint can expose plaintext after decryption.
Encryption does not hide every form of metadata. TLS, for example, does not inherently hide transmitted lengths.
A signature proves only what the verification key and surrounding trust process justify.
Key compromise can invalidate the protection that depends on that key.
Custom algorithms and improvised combinations are difficult to evaluate and easy to misuse.
Algorithm and key-length choices change as attacks, standards, and computing capabilities evolve.

Use maintained libraries and current standards. Keep keys separate from protected data where the threat model requires it. Record key ownership, purpose, state, and replacement dates. Treat cryptographic agility as an operational capability, not as a promise to swap algorithms instantly.

A practical decision sequence

Name the asset and attacker.
State the required security properties.
Select a current protocol or construction that already provides them.
Identify every key, nonce, salt, and trust anchor.
Define generation, distribution, storage, rotation, revocation, recovery, and destruction.
Test failure behavior, not only successful encryption and decryption.
Monitor standards and plan transitions before an algorithm becomes unacceptable.