Ultimate Cryptography Guide

Threat modeling changes everything

The same algorithm can be acceptable in one context and strategically weak in another. A short-lived internal session and a decades-long classified archive do not carry the same threat horizon, attacker profile, data value, or migration urgency.

Confidentiality

Confidentiality means that only authorized actors can read protected information. This is the goal most people think of first when they hear “cryptography”, but it is only one dimension of security. In practice, confidentiality usually relies on symmetric encryption for actual data protection, while asymmetric mechanisms are used to establish or protect the symmetric keys.

Confidentiality is not just about the ciphertext. It also depends on endpoint trust, memory safety, backups, logs, metadata, traffic shape, export controls, key custody, archive retention, and sometimes physical or sovereign boundaries.

Where confidentiality matters most

• Confidential communications between systems, people, or organizations
• Data at rest in storage, backups, laptops, databases, and archives
• High-value documents, source code, trade secrets, defense materials, regulated data
• Long-term archives where exposure years later would still matter
• Internal operational data that could be weaponized if leaked

Integrity

Integrity means that unauthorized modifications become detectable. It applies to files, messages, software packages, firmware, transactions, logs, API payloads, and administrative commands. Integrity can be provided through hashes, MACs, signatures, or authenticated encryption depending on the trust model.

Integrity is frequently underestimated because teams assume confidentiality implies integrity. It does not. A system may encrypt data while still allowing undetected modification if the encryption mode or protocol design is wrong.

Integrity questions

• Can an attacker alter the content without detection?
• Can the receiver verify that nothing changed in transit or storage?
• Can replay, truncation, substitution, or reordering attacks occur?
• Does the mechanism detect tampering immediately or only later?

Authenticity

Authenticity answers the question: who really produced this message, artifact, session, or command? It matters in human communications, internal APIs, code signing, device onboarding, firmware updates, admin actions, payment systems, and defense or industrial control channels.

Authenticity is not only about identity labels. It is about trustable origin bound to a cryptographic proof and a governed trust framework. A username in a header proves nothing. A certificate with no trust chain or ownership governance also proves very little.

Where authenticity is critical

• Software and firmware distribution
• Internal service-to-service APIs
• Remote administration and privileged workflows
• High-trust documents, approvals, and evidence trails
• Critical command and control systems

Non-repudiation

Non-repudiation is the most abused word in cryptography discussions. It is often treated as if a signature automatically guarantees that a sender can never deny an action. That is false in practice. A signature may support non-repudiation only if identity proofing, secure issuance, exclusive key control, logging, audit trails, and process governance are all strong enough.

In other words, non-repudiation is never only mathematical. It is mathematical + operational + legal + organizational.

Requirements for meaningful non-repudiation

• Strong identity proofing before key issuance
• Clear ownership of the signing key
• No shared uncontrolled access to the private key
• Reliable timestamping and audit evidence
• Revocation and exception records
• Documented processes that can withstand dispute

Forward secrecy

Forward secrecy means that if a long-term secret is compromised later, previously captured session traffic should still remain protected. This is a strategic property for transport protocols and a crucial defense against delayed exploitation. It matters even more when considering long-term interception and future quantum migration pressure.

Without forward secrecy, a leaked server private key or long-term key agreement secret may expose large volumes of historical traffic. With forward secrecy, compromise is more localized in time and scope.

Why forward secrecy matters

• It reduces the blast radius of future long-term key compromise.
• It is highly relevant for intercepted traffic stored by powerful adversaries.
• It supports long-horizon security in environments where archives or captured sessions may be revisited later.

Trust distribution

Trust distribution is the least discussed security goal and one of the most important at scale. It asks how trust is delegated, segmented, constrained, audited, rotated, and revoked across a system. In practice, this means PKI design, issuer scoping, root and intermediate strategy, HSM/KMS boundaries, key hierarchies, and separation of duties.

A system can use excellent algorithms and still fail because trust is distributed badly: one oversized root, one shared admin key, one over-privileged intermediate, one unmanaged signing flow, one opaque appliance with hidden certificates, or one impossible-to-revoke dependency.

What good trust distribution looks like

• Roots are tightly protected and rarely used
• Intermediates are scoped and segmented
• Private keys live in controlled boundaries
• Roles are separated between issuance, approval, and operation
• Trust can be revoked without collapsing the whole system

Adversaries rarely attack the mathematics directly

In practice, attackers go after the layers surrounding cryptography: endpoints, exported private keys, certificate issuance abuse, weak revocation, phishing, privileged sessions, CI/CD signing flows, stored archives, and exposed metadata. Understanding how adversaries operate is more useful than memorizing abstract categories.

Data lifetime is one of the most important threat parameters

Cryptographic urgency depends heavily on how long the protected information remains valuable. A payment session lasting a few seconds is not in the same strategic category as a defense archive, a software-signing key, a classified design dossier, or a sovereign communications history.

The longer the data remains sensitive, the more important future-looking threats become: archive theft, delayed decryption, long-term key exposure, and evidence disputes years after creation.

Harvest Now, Decrypt Later

“Harvest Now, Decrypt Later” means an adversary can collect encrypted traffic or archives today, store them for years, and attempt decryption when new capabilities become available later. This changes how we think about long-lived confidentiality: the danger is not only future cryptanalytic capability, but current large-scale collection of data whose value persists.

This matters most where archives, strategic communications, sensitive industrial plans, sovereign data, or long-retention regulated evidence remain valuable beyond the current technical lifetime of a classical cryptosystem.

Typical HN-DL candidates

• Defense or sovereign communication archives
• Long-retention legal, intelligence, or compliance records
• High-value industrial IP and design repositories
• Strategic diplomatic or command communications
• Any archive whose sensitivity outlives current classical assumptions

Risk prioritization must be strategic, not cosmetic

Not every encrypted workflow deserves the same migration effort or the same urgency. A good priority model balances adversary capability, business impact, data lifetime, dependency complexity, operational feasibility, and trust-chain fragility.

Common threat-modeling mistakes

Entropy sources

Entropy comes from physical or system phenomena that are assumed to be difficult to predict: hardware noise, oscillator jitter, thermal effects, interrupt timing, user input timing, disk behavior, or dedicated entropy hardware. The key point is not “complexity”, but unpredictability from the attacker’s point of view.

Good cryptographic systems do not trust a single fragile source blindly. They collect, condition, mix, and health-check entropy before using it to seed the deterministic generator that will feed keys, nonces, tokens, or ephemeral values.

Common entropy sources

RNG pipeline: from entropy to usable randomness

Real systems usually do not use raw entropy directly for every cryptographic output. Instead, they gather entropy, condition it, seed a deterministic random bit generator (DRBG), and then expand that seed into many cryptographic values. This is efficient and practical, but it creates a critical dependency: if the seed or DRBG state is weak, the whole output stream is weak.

Main pipeline components

Nonces, IVs, and uniqueness rules

Nonces and IVs are often misunderstood because different schemes require different properties. Some only require uniqueness; others require unpredictability; some need both. Reusing a nonce where uniqueness is mandatory can completely destroy confidentiality or integrity, even if the key itself remains secret.

This is why nonce handling is one of the most dangerous operational details in cryptographic engineering. Teams may choose strong algorithms and still break them simply by generating, storing, incrementing, or reusing nonces incorrectly.

Typical nonce / IV requirements

Common failure patterns

Engineering checklist

Hash functions

A cryptographic hash function maps arbitrary input data to a fixed-size digest. Good hash functions are designed so that tiny input changes produce very different outputs, and so that attackers cannot easily find collisions or reconstruct the original input from the digest alone. In practice, hashes are used as integrity anchors, fingerprints, indexing helpers, signature inputs, and building blocks inside higher-level constructions.

Hashes are deterministic: the same input always gives the same output. That is useful for verification, but it also explains why hashing is not a confidentiality tool. If an attacker knows or can guess the original input, they can hash it too and compare results.

Typical properties expected from a strong hash

• Preimage resistance: given a digest, finding an input should be hard.
• Second-preimage resistance: given one input, finding another with the same digest should be hard.
• Collision resistance: finding any two distinct inputs with the same digest should be hard.
• Avalanche behavior: small input changes produce major digest changes.
• Determinism: same input, same digest, always.

MACs and HMAC

A MAC, or Message Authentication Code, is designed to prove both integrity and authenticity between parties sharing a secret. HMAC is one of the most widely used MAC constructions and combines a shared secret with a hash function in a structured way. The crucial difference from a raw hash is that an attacker without the secret key should not be able to generate a valid tag for a forged message.

HMAC is common in internal APIs, webhooks, service-to-service protection, signed tokens, storage validation, and protocol message authentication. It is especially useful when asymmetric signatures would be too heavy or unnecessary, and where both sides already share trust through a managed secret.

What HMAC gives you

• Integrity of the protected message
• Authenticity relative to the shared secret holder
• Resistance to simple tampering by parties lacking the secret
• A practical and efficient tool for symmetric trust domains

Key Derivation Functions

A KDF transforms secret material into one or more derived keys for specific uses. This is essential because a single raw secret should rarely be reused directly across multiple roles. Key derivation allows separation by context, label, purpose, algorithm, direction, or session. Without this separation, systems risk dangerous key reuse across encryption, authentication, signing, transport, or storage functions.

KDFs are used in TLS-like session establishment, password-based key generation, storage encryption hierarchies, HSM/KMS workflows, token derivation, and multi-stage protocols where one root secret must safely produce many scoped subkeys.

Why KDFs are critical

• They enforce key separation across different uses.
• They prevent one compromise from automatically spreading across all cryptographic functions.
• They make protocol key schedules manageable and consistent.
• They allow salts, labels, and context strings to scope derived outputs safely.
• They are essential in password handling and session key establishment.

What these primitives are not

Confusion around hashes, MACs, and KDFs usually comes from assuming that every cryptographic function “protects data” in the same way. They do not. Each has a specific role and specific limits. Misusing one as a substitute for another creates fragile systems that may look correct in code review but fail under real attack.

Engineering checklist

The AES family

AES is the dominant block cipher in modern systems. It is widely standardized, broadly accelerated in hardware, deeply embedded in software stacks, and used across transport, storage, database protection, HSM workflows, tokens, and secure device communication. AES by itself is only the core primitive: the actual security properties depend on the mode of operation wrapped around it.

Engineers often say “we use AES” as if that fully described the security posture. It does not. AES-CBC, AES-GCM, AES-XTS, and other constructions behave very differently. The security outcome depends on whether authenticity is built in, whether nonce / IV handling is correct, and whether the data model is transport-oriented or storage-oriented.

Why AES is so widely deployed

• Strong standardization and ecosystem maturity
• Excellent hardware acceleration on many platforms
• Good performance for transport and storage workloads
• Extensive support in libraries, devices, appliances, and standards
• Operational familiarity across industries

ChaCha20 and software-friendly symmetric protection

ChaCha20 is widely valued for its strong software performance profile and its suitability in environments where dedicated AES acceleration may be weaker, unavailable, or less convenient. It is commonly paired with Poly1305 to provide authenticated encryption in the form of ChaCha20-Poly1305, which is widely used in transport and application protocols.

In practice, ChaCha20-based authenticated encryption is especially attractive in mobile, constrained, cross-platform, or software-centric environments where consistent performance and simpler deployment characteristics matter. It is not “better than AES in every way”; rather, it is an excellent alternative with strong real-world engineering value.

Why ChaCha20 matters

• Excellent performance in many software-only environments
• Strong fit for mobile and heterogeneous deployments
• Commonly used as part of authenticated encryption
• Useful alternative where AES hardware acceleration is less ideal

Authenticated encryption is the modern baseline

Encrypting without protecting integrity is often not enough. Modern application and transport design usually needs authenticated encryption, meaning confidentiality and integrity protection are delivered together in one coherent construction. This reduces the chance that teams will combine separate pieces incorrectly or forget to authenticate the ciphertext.

AEAD, or Authenticated Encryption with Associated Data, is especially important because many protocols need to protect not only the payload, but also ensure that selected metadata, headers, counters, or context fields are bound to the encrypted message without necessarily encrypting those fields themselves.

Why AEAD matters

• Provides confidentiality and integrity together
• Reduces dangerous “encrypt first, authenticate later” design mistakes
• Supports protected associated data for protocol context
• Improves security posture in transport, APIs, messaging, and secure storage workflows

Disk encryption is a different problem from message encryption

Storage protection has different constraints from transport or messaging. Disk encryption must handle block devices, predictable structure, sector updates, partial writes, performance constraints, and offline theft scenarios. That is why storage modes such as AES-XTS exist: they are designed for at-rest block-oriented protection rather than general-purpose message authenticity.

Engineers sometimes incorrectly assume that a disk encryption mode can simply be reused for files, archives, or protocol messages. That is a category mistake. Storage modes and transport/message modes solve related but different problems.

What disk encryption is good at

• Protecting data if physical media is stolen
• Reducing exposure from lost laptops or removed drives
• Securing block storage against offline reading without the key

What disk encryption does not automatically solve

• File-level sharing or secure exchange
• Authenticated network transport
• Protection once the system is already running and unlocked
• Strong origin proof or message-level authenticity

Engineering checklist

How RSA is constructed

RSA begins by generating two large prime numbers, commonly called p and q. Their product forms the modulus n, which becomes part of both the public and private key material. A public exponent e is chosen, and a corresponding private exponent d is computed so that the two work together over the arithmetic structure derived from the primes.

The public key typically contains (n, e). The private side depends on d and often additional optimized values derived from the prime factors. The security intuition is that the public information should not make it feasible to reconstruct the private information in practice.

The security basis of RSA

The classical security story of RSA is tied to the practical difficulty of recovering the private structure from the public modulus. In intuitive terms, the public modulus is easy to compute from the primes, but going backward is believed to be hard at the necessary scale for strong key sizes. This asymmetry is what makes RSA useful as a public-key system.

However, “hardness” in cryptography always means hardness under specific attack models, assumptions, implementation quality, and available computational power. RSA is not secured by mythology. It is secured by a combination of mathematical assumptions, conservative key sizes, padding discipline, implementation quality, and key custody.

What the security story depends on

• Strong prime generation with high unpredictability
• Sufficient modulus size for the intended risk horizon
• Correct padding and mode selection
• Side-channel resistant implementations where needed
• Secure storage and lifecycle management of the private key

What RSA is actually used for today

In modern systems, RSA is rarely used to encrypt large payloads directly. That is not its practical role. Instead, RSA is mostly used for digital signatures, certificate-based trust, and in some legacy or compatibility scenarios for protecting a small secret such as a symmetric session key. Bulk data encryption is almost always done with symmetric cryptography once the keying material is established.

This distinction matters because many non-specialists imagine RSA as “the algorithm that encrypts files”. That is not how most serious systems operate. RSA is far more important as a trust and signature mechanism than as a payload encryption engine.

Typical RSA roles

Limits and operational realities

RSA often appears simple in diagrams but becomes delicate in real systems. Padding mistakes, poor error handling, side-channel leakage, unsafe serialization, key export practices, legacy protocol compatibility, and trust-chain sprawl create far more realistic failure paths than brute-force attacks against the modulus itself.

RSA also faces strategic limits. It is computationally heavier than symmetric encryption, less elegant than modern elliptic-curve deployments in some contexts, and not considered future-proof under large-scale quantum threat models. This does not make RSA “broken today”, but it does make it a major migration dependency.

Where RSA fails in practice

• Private keys exported to files, backups, or admin workstations
• Unsafe or obsolete padding choices
• Protocol branches that leak too much through error behavior
• Timing / cache / side-channel implementation weaknesses
• Poor certificate governance and unmanaged intermediates
• Long-lived dependencies with no migration owner

Architect checklist