Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Cryptography

Cryptography is the engineering discipline of building mathematical primitives that protect data and communications against adversaries — and the larger discipline of composing those primitives into protocols, systems, and architectures that hold up under real conditions. This page is the umbrella introduction. The subpages linked at the end go deep on individual primitives, protocols, and key management.

The discipline gets called by several names in adjacent contexts. Cryptography is the study and engineering of these techniques. Cryptanalysis is the study of breaking them. Cryptology is the formal umbrella term covering both, mostly used in academic and military contexts. “Crypto” as shorthand referred to cryptography for the better part of a century; in recent years it has been claimed by the cryptocurrency community, which is a different and only partially overlapping discipline. On this site, “crypto” means cryptography unless we explicitly say otherwise.

The four goals

Almost every cryptographic system in production exists to provide some combination of four properties. They are not the same property, they are not always all present, and confusing them is the most common source of design error in systems that use cryptography incorrectly.

Confidentiality. Only intended recipients can read the data. This is the property most people associate with “encryption” — and it is one of four, not the whole picture.

Integrity. The data has not been modified in transit or storage, accidentally or deliberately. A message that arrives unchanged but unreadable has integrity without confidentiality. A message that arrives readable but corrupted has confidentiality without integrity. Both happen.

Authentication. The party at the other end of the communication is who they claim to be. Authentication of a user, a server, or a piece of software are all different problems, and the cryptographic primitives that solve them overlap but are not identical.

Non-repudiation. The sender cannot later credibly deny having sent the message. This property requires asymmetric cryptography — only the holder of a private key could have produced a given signature, which is what makes the signature meaningful as evidence. Symmetric cryptography does not provide non-repudiation, because both parties hold the same key.

Real systems pick a subset. TLS provides confidentiality, integrity, and server authentication, but not non-repudiation (the server’s session key is symmetric). A signed software update provides integrity, authentication, and non-repudiation, but not confidentiality — anyone can read the update, the signature just proves who built it.

The three primitive families

Modern cryptography rests on three families of primitives. Most cryptographic protocols are compositions of one or more from each.

Symmetric cryptography

A single shared secret key is used to both encrypt and decrypt. The key has to be known to both parties in advance, which means symmetric cryptography solves the easy problem (what to do once you have a shared key) and not the hard one (how to establish the shared key in the first place).

Symmetric cryptography divides into block ciphers, which operate on fixed-size blocks of data (AES is the canonical example, with 128-bit blocks), and stream ciphers, which produce a continuous keystream that gets combined with the plaintext (ChaCha20 is the current state of the art). Block ciphers are used inside modes of operation — GCM, CBC, CTR, XTS — that determine how blocks are chained together. The mode is part of the security model. AES in ECB mode is a famous example of how the choice of mode can entirely defeat the choice of cipher.

Symmetric primitives are fast. Modern CPUs have hardware acceleration for AES (the AES-NI instruction set, present since Intel’s Westmere generation in 2010), and gigabit-per-second throughput on a single core is routine.

Asymmetric (public-key) cryptography

A mathematically linked key pair is used: one key encrypts, the other decrypts; one key signs, the other verifies. The public key can be distributed openly. The private key is held secret by its owner. This is the family that solves the key-distribution problem — Alice can send Bob a confidential message using Bob’s public key without ever having shared a secret with Bob in advance.

The canonical families:

  • RSA, based on the difficulty of factoring large integers. Still widely deployed, still secure at appropriate key sizes (2048 bits minimum, 3072 bits preferred for long-term use), but increasingly displaced by elliptic curve methods because RSA key sizes grow inconveniently fast as security levels rise.
  • Elliptic Curve Cryptography (ECC), based on the difficulty of the discrete logarithm problem on elliptic curves. Smaller keys, faster operations, equivalent security. Curve25519 and P-256 are the two most-deployed curves; Ed25519 is the standard for signatures.
  • Post-quantum families — lattice-based, code-based, hash-based, and multivariate cryptography. These are the algorithms that will replace RSA and ECC once quantum computers reach the scale that breaks integer factoring and discrete logarithms. The transition is underway. See the post-quantum section below.

Asymmetric primitives are slow compared to symmetric ones — often by two or three orders of magnitude. Real protocols almost never use asymmetric cryptography to encrypt actual data. Instead, they use asymmetric cryptography to negotiate a symmetric session key, then switch to symmetric cryptography for the bulk data. TLS is the textbook example of this hybrid pattern.

Hash functions

A hash function takes an input of arbitrary length and produces a fixed-length output. A good cryptographic hash has three properties: preimage resistance (given a hash, you can’t find an input that produces it), second-preimage resistance (given an input, you can’t find a different input with the same hash), and collision resistance (you can’t find any two inputs with the same hash). The canonical modern hash families are SHA-2 (SHA-256, SHA-384, SHA-512) and SHA-3.

Hash functions are the workhorse primitive. They underlie message authentication codes, digital signatures, password storage, blockchain consensus, file integrity, and many other constructions. They are not encryption — there is no key, no decryption operation, and the output is meant to be one-way.

On top of these three families sit several composite constructions worth knowing by name:

  • Message Authentication Codes (MACs) combine a hash function with a shared secret key to produce a tag that verifies both the integrity and the authenticity of a message. HMAC is the most widely deployed MAC construction.
  • Digital signatures combine a hash function with an asymmetric key pair to produce a tag that proves a specific private key was used to sign a specific message. The verifier needs only the public key.
  • Key Derivation Functions (KDFs) turn one secret (often a password, sometimes a low-entropy shared seed) into one or more keys suitable for cryptographic use. PBKDF2, scrypt, Argon2, and HKDF are the constructions you will see most often.
  • Authenticated Encryption with Associated Data (AEAD) combines encryption and authentication in a single primitive. AES-GCM and ChaCha20-Poly1305 are the two dominant AEAD constructions in modern protocols.

Where these primitives end up in practice

Almost no software calls a cryptographic primitive directly. The primitives are composed into protocols and systems that solve specific problems. The major ones worth knowing as a baseline:

  • TLS (Transport Layer Security) — the protocol that protects the vast majority of internet traffic. Uses asymmetric cryptography for authentication and key exchange, symmetric AEAD for bulk encryption, and hash functions throughout. TLS 1.3 is the current version; earlier versions remain deployed and have known weaknesses.
  • SSH (Secure Shell) — remote login, file transfer, and tunneled access. Similar primitive composition to TLS but a different protocol family.
  • PKI (Public Key Infrastructure) — the trust framework that lets one party verify another’s public key by chaining trust through certificate authorities. PKI is more politics than mathematics. The mathematics is the easy part.
  • Disk encryption — LUKS on Linux, FileVault on macOS, BitLocker on Windows. AEAD modes for the data itself, key management through user passwords, TPMs, or recovery keys.
  • Code signing — the mechanism that lets a system verify that an executable, package, or update came from a specific signer and has not been modified. Authenticode on Windows, GPG signatures in Linux package managers, Apple’s notarization, Sigstore for open-source supply chains.
  • End-to-end encrypted messaging — Signal, WhatsApp, iMessage. The Double Ratchet algorithm and X3DH key agreement are the underpinnings of the modern E2EE messaging family.
  • Blockchain and cryptocurrency — hash functions for consensus and Merkle trees, digital signatures for transaction authorization, and various more exotic primitives for newer chains.

Each of these will get its own subpage. The pattern that connects them is hybrid: asymmetric cryptography handles trust establishment and key exchange, symmetric cryptography handles the bulk data, and hash functions thread through everything.

What “broken” actually means

The word “broken” in cryptography contexts gets used to mean several different things. Telling them apart matters because they have very different operational implications.

Algorithmic breaks are the rarest and most consequential. The mathematical foundation of the primitive has been shown to be weaker than originally thought. DES is broken in this sense (56-bit keys are exhaustively searchable). MD5 and SHA-1 are broken in the collision-resistance sense. Quantum computers will break RSA and ECC in this sense once they reach sufficient scale.

Implementation breaks are far more common. The mathematics is fine; the code is wrong. Padding oracle attacks, timing side channels, branch-predictor leaks, fault injection, and entropy failures all fall here. The primitive specification is intact; the deployed implementation leaks. Heartbleed, ROCA, and Spectre-class attacks against cryptographic operations are all in this family. The mitigation is to use well-reviewed library implementations (libsodium, BoringSSL, the Rust crypto ecosystem) and to keep them updated.

Parameter weakness means the algorithm is sound but the parameters being used in deployment are no longer adequate. RSA at 1024 bits is in this category. AES at 128 bits is not — yet — but the recommendation for new deployments is increasingly 256 bits. The mitigation is rotation.

Misuse is the largest category by incident count. The primitive is fine, the implementation is correct, but it is being used in a way that does not provide the security property the deployer assumes. Encrypting without authenticating (use AEAD). Reusing a nonce in a stream cipher. Storing passwords as plain SHA-256 hashes instead of with a password-specific KDF. Implementing cryptographic protocols by reading the spec instead of using a vetted library. The mitigation is to use high-level constructions (Signal Protocol, libsodium’s crypto_box, age) that make misuse difficult.

The hard part: key management

The mathematics of cryptography is rigorous and well-understood. The deployment of cryptography in real systems is dominated by key management — the much harder problem of where keys come from, where they live, how they are rotated, and who has access. Almost every cryptographic breach in production traces back to a key management failure, not a primitive failure.

The core key management problems are:

  • Key generation must come from a sufficient source of entropy. Embedded systems and virtual machines have historically been bad at this; modern operating systems provide reasonable kernel CSPRNGs but the deployment must actually use them.
  • Key storage must keep private keys away from anything that should not have them. Hardware Security Modules (HSMs), Trusted Platform Modules (TPMs), and secure enclaves are the hardware answers. Cloud KMS services are the managed-service answers. Plaintext keys in environment variables, in configuration files, or in source control are the failure modes.
  • Key rotation is the practice of periodically replacing keys to limit the blast radius of a future compromise. Rotation is operationally hard because every system holding a key needs to know about the new one.
  • Key escrow and recovery are the policy questions about who, if anyone, can access encrypted data when the original key holder cannot. Every answer is a tradeoff between recoverability and the value of the encryption itself.

Key management gets its own subpage because the depth here is greater than the rest of cryptography combined.

The post-quantum transition

Large-scale quantum computers — the kind that do not yet exist but are the subject of credible engineering effort across multiple national programs and private companies — would break RSA and elliptic curve cryptography. Shor’s algorithm, published in 1994, solves the integer factoring and discrete logarithm problems efficiently on a quantum computer of sufficient scale. Grover’s algorithm reduces the effective key length of symmetric primitives by half, which is mitigated by doubling key sizes.

The cryptography community has spent the last decade preparing for this. NIST ran a standardization process from 2016 through 2024, evaluating dozens of candidate post-quantum algorithms. The first standards have now been finalized:

  • FIPS 203 (ML-KEM) — Module-Lattice-based Key Encapsulation Mechanism. Replaces RSA and ECC key exchange. Based on the lattice problem Module-LWE.
  • FIPS 204 (ML-DSA) — Module-Lattice-based Digital Signature Algorithm. Replaces RSA and ECC signatures for most uses. Also lattice-based.
  • FIPS 205 (SLH-DSA) — Stateless Hash-Based Digital Signature Algorithm. A conservative, hash-only signature scheme used where ML-DSA’s assumptions are too aggressive.

The transition is in progress, not complete. Hybrid deployments — running classical and post-quantum primitives side by side — are the current best practice for production systems that need to be safe against both today’s adversaries and tomorrow’s quantum-capable ones. The Quantum Computing page on this site goes deeper.

Standards bodies

Cryptographic standards come from several places, and knowing which body publishes what helps when reading specifications.

  • NIST (National Institute of Standards and Technology) publishes the FIPS series (Federal Information Processing Standards) and the SP 800 series (Special Publications). FIPS 197 is AES. FIPS 180-4 is the SHA-2 family. FIPS 186-5 is the digital signature standard. SP 800-57 covers key management.
  • IETF (Internet Engineering Task Force) publishes RFCs that specify cryptographic protocols and their use. RFC 8446 is TLS 1.3. RFC 8032 is Ed25519. RFC 9106 is Argon2.
  • ISO/IEC publishes its own parallel cryptographic standards, used more heavily outside the United States.

In practice, NIST standards dominate US federal systems, IETF standards dominate the open internet, and the two bodies coordinate enough that the resulting deployed cryptography is broadly compatible.

Where to go next on this site

The subpages under Cryptography will go deeper than this overview can:

  • Symmetric Cryptography — block and stream ciphers, AEAD constructions, modes of operation.
  • Public-Key Cryptography — RSA, ECC, key exchange, the math behind the primitives.
  • Hash Functions and MACs — SHA-2, SHA-3, HMAC, the construction patterns.
  • Public Key Infrastructure (PKI) — certificates, certificate authorities, trust chains, revocation.
  • TLS Internals — protocol design, version history, configuration in practice.
  • Key Management — generation, storage, rotation, HSMs and cloud KMS.
  • Post-Quantum Cryptography — covered alongside Quantum Computing.

If something here is wrong or incomplete, the goal is to fix it — these pages are meant to be durable references, not snapshots.