Cryptography provides tools for confidentiality, integrity, authentication and evidence supporting non-repudiation. These properties are distinct: encryption alone does not prove who created a message, and a valid signature does not establish that its content is true.
Forensic interpretation requires the actual scheme, mode, keys, parameters and implementation context. Symmetric and public-key techniques often work together, but not every system uses the same hybrid sequence. Classical ciphers illustrate principles; they are not suitable protection for modern sensitive data.
By the end of this topic you will be able to:
- Distinguish confidentiality, integrity, authentication and non-repudiation claims.
- Explain symmetric, public-key and hybrid constructions without assuming all key pairs encrypt.
- Compare classical substitution and transposition with modern encryption.
- Identify key derivation, lifecycle and forward-secrecy limits in evidence.
- CIAN
- A teaching shorthand for confidentiality, integrity, authentication and non-repudiation. Actual assurances depend on the complete scheme and context.
- Symmetric key
- Secret keying material used by a symmetric construction. Secure distribution or derivation and correct use remain essential.
- Asymmetric key pair
- Related public and private material used by a particular public-key scheme; capabilities differ between encryption, signatures and key agreement.
- Hybrid encryption
- A construction combining public-key mechanisms with symmetric protection. The protocol defines how keys, identities and messages are bound.
- Confusion and diffusion
- Design ideas describing complex key relationships and spreading input influence. Statistical appearance alone does not establish security.
- Perfect Forward Secrecy
- A protocol property limiting the effect of later long-term-key compromise on earlier session keys under the stated assumptions. It does not protect plaintext already retained at an endpoint.
Cryptography Goals and the CIAN Model
Confidentiality limits disclosure of plaintext. Integrity detects unauthorised modification under the construction’s assumptions. Authentication concerns an asserted origin or entity. Non-repudiation involves evidence and operational/legal context, not an algorithm’s unconditional promise.
A bare hash is not a secret-key authenticator: an attacker able to replace both a file and its unchecked hash can replace them together. A MAC requires a secret; a signature is verified with a public key.
An AEAD construction such as correctly used AES-GCM authenticates protected data under a key and can also authenticate associated data without encrypting it. It does not establish which human operated a shared endpoint.
CBC encryption alone is malleable and does not supply message integrity. Whether a padding oracle exists depends on implementation behaviour; absence of a MAC is not proof that a particular oracle was exploitable.
A digital signature can support integrity and origin claims under a validated key binding. Either holder of a shared MAC key may generate the MAC, which limits third-party attribution. Compromised signing keys and automated signers also matter.
In a report, name the property actually tested, validation inputs and remaining limits. Do not claim that encryption alone establishes evidence authenticity or that every cryptographic issue is exempt from challenge.
Symmetric vs Asymmetric: Speed, Scale and the Key Distribution Problem
Symmetric encryption is generally efficient for bulk data. Public-key mechanisms address different tasks, including key establishment and signatures; a signing-only key cannot automatically be used for encryption.
Scroll horizontally if needed to see the full table.
A fully connected network with a unique secret for each pair of N parties needs N(N−1)/2 pairwise secrets. This illustrates one arrangement, not a requirement for every symmetric system; key distribution centres and other architectures exist.
Public-key publication does not remove trust management. An attacker can substitute an unauthenticated key. Certificates, verified fingerprints or another suitable mechanism bind keys to the intended peer.
Hybrid systems establish or encapsulate keying material, derive purpose-specific keys and protect data symmetrically. Authentication may use signatures, pre-shared keys or other protocol mechanisms. The details and number of keys change over the session.
TLS 1.3 supports ephemeral finite-field or elliptic-curve Diffie–Hellman and pre-shared-key modes. It does not mandate ECDHE in every session, nor use RSA key transport. Its 0-RTT data has distinct replay and forward-secrecy limits.
Classical Substitution and Transposition Ciphers
Classical ciphers help explain substitution, transposition and attack models. They may occur in teaching or obfuscation, but their presence does not imply modern cryptographic strength.
A Caesar cipher shifts letters by a fixed amount. With a 26-letter alphabet there are 26 shifts including the identity, or 25 non-identity shifts. Exhaustive testing is easy.
Monoalphabetic substitution preserves language statistics. Its 26! permutations do not imply a corresponding practical security level; message length, language and available clues affect analysis.
Vigenère repeats a sequence of shifts. Repeated-pattern spacing and statistical analysis can suggest a key length; short ciphertexts and different variants require care.
Playfair substitutes letter pairs, while the Hill cipher applies an invertible matrix modulo the alphabet size. Hill key recovery needs enough suitable independent known blocks; not every arbitrary set of plaintext/ciphertext pairs is invertible.
Transposition rearranges symbols and preserves their single-symbol counts. Rail-fence and columnar constructions are teaching examples; order patterns and known plaintext can assist analysis.
A one-time pad has perfect-secrecy properties when the secret key is independently uniform, at least the message length and never reused. It does not inherently authenticate messages, and secure key distribution remains difficult.
Ciphertext appearance is not a security proof. Compression, file headers, encoding and small samples affect histograms. A skewed distribution alone does not establish broken encryption; high entropy does not prove encryption.
Key Types, Key Derivation and Key Lifecycle
Identify a key’s role, algorithm, origin, storage, allowed operations and lifetime. Public/private, shared, master, derived, wrapping and session labels describe different dimensions; they do not dictate universal expiry periods.
Password-based derivation, such as PBKDF2 or Argon2id, combines a password with a salt and configured cost. Password entropy, parameters and implementation matter; there is no universal iteration threshold that makes every system secure.
HKDF extracts and expands keying material for protocol purposes. It is not a password-stretching replacement, and cannot manufacture entropy absent from the input.
Use purpose/context separation and record the actual KDF, salt, cost, output length and version. A salt is generally not a secret; it helps prevent cross-record reuse of precomputed work rather than making a weak password strong.
Key management covers generation, establishment/distribution, storage, use, replacement, recovery and retirement as applicable. Cryptoperiods depend on role and risk; “rotate every CA key annually” is not a universal rule.
Hardware-backed storage can restrict extraction but does not guarantee that an authorised or compromised process cannot request an operation. Distinguish a non-exportable key from inaccessible plaintext.
Destruction records document a process; they do not prove every historical copy was erased. Preserve relevant recovery material and key metadata under appropriate authority and handling controls.
Design Properties: Confusion, Diffusion, Avalanche, Forward Secrecy
Confusion concerns a complex key-to-output relationship; diffusion spreads input influence. The avalanche criterion describes output-bit changes statistically, not a mandatory exact half for every individual input pair.
Avalanche behaviour and the absence of known weak keys are useful design considerations, not standalone proof of resistance to all attacks. Full security analysis considers structure, attack models and implementation.
Forward secrecy limits retrospective consequences of a long-term-key compromise when the protocol establishes suitable fresh secrets and removes them appropriately. Ephemeral naming alone is insufficient.
With suitable captured TLS 1.2 RSA-key-transport traffic and the relevant private key, retrospective decryption may be possible. Ephemeral DH sessions are different. TLS 1.3 PSK-only operation and 0-RTT need their own assessment.
Endpoint compromise may expose stored plaintext, backups or current keys despite forward secrecy. Ratchet protocols do not universally reveal “only future messages”; the timing and scope of compromise and subsequent recovery mechanisms matter.
The Cryptanalytic Attack Taxonomy
Ciphertext-only, known-plaintext, chosen-plaintext and chosen-ciphertext models describe an adversary’s capabilities. They are not a universal hardest-to-easiest ranking of real investigations.
Chosen-ciphertext definitions restrict access to the challenge ciphertext and differ in timing/adaptivity. A protocol’s required security notion must match how it is deployed.
Exhaustive search depends on effective key entropy and per-guess cost. A 256-bit container protected by a weak password can be attacked through its password derivation without enumerating all cipher keys.
Side channels exploit implementation leakage such as timing, power or cache behaviour. Hardware acceleration can address some leakage paths without proving an entire application constant-time or invulnerable.
Replay concerns reuse of a previously valid message. Integrity protection alone may not reject it; freshness mechanisms and receiver state must be correctly bound and checked.
Key theft, unsafe randomness, nonce reuse and protocol misuse often matter alongside mathematical attacks. Report the actual observed weakness rather than infer all encryption is breakable or beyond forensic examination.
Diffie–Hellman, Signatures and PKI: How the Pieces Fit
Diffie–Hellman establishes shared material from public contributions and private secrets. In a suitable finite-field group, A = g^a mod p and B = g^b mod p lead to the common value g^(ab) mod p. Group selection, validation and key derivation matter.
Unauthenticated DH does not establish peer identity and is vulnerable to an active man-in-the-middle. Appropriate signatures, pre-shared authentication or another validated protocol mechanism can bind the exchange.
Encryption and signature schemes that share a mathematical family still have different operations and security requirements. RSA-PSS is probabilistic; do not describe all RSA signatures as deterministic. ECDSA nonces may be generated deterministically by an approved scheme rather than requiring a new external random draw.
PKI supplies key-binding and trust machinery under a defined policy; it is not one country’s exclusive cryptographic model. National legal recognition belongs in the legal-framework material when relevant.
Continue with Symmetric Cryptosystems for block/stream ciphers and modes, and the signatures lesson for certificate validation.
Check Your Understanding
Sources
- 1.Key management and security services · NIST SP 800-57 Part 1 Rev. 5
- 2.TLS 1.3 modes, authentication and 0-RTT limits · RFC 8446
- 3.HKDF extract and expand · RFC 5869
- 4.Argon2 password hashing · RFC 9106
- 5.RSA schemes including PSS · RFC 8017