Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
CIAN goals, symmetric vs asymmetric trade-offs, the key-distribution problem, classical substitution and transposition ciphers, key types, confusion and diffusion, the forensic attack model, and how CCA India and UPI bind these ideas to real Indian infrastructure.
Most digital forensics work eventually hits a cryptographic boundary. A WhatsApp database is sealed with AES-256-GCM. A seized laptop's disk is wrapped under BitLocker's AES-XTS. An intercepted email between a fraud syndicate uses S/MIME with RSA-2048 signatures and AES-128 content encryption. An examiner who treats crypto as a black box will produce reports that fall apart on cross-examination, because the defence's expert will ask which mode, which key length, which IV, and whether the signature scheme is deterministic.
This topic builds the foundation for every cryptography topic in Module 7. It starts with what cryptography actually promises (confidentiality, integrity, authentication, non-repudiation), separates symmetric from asymmetric primitives by what they are good at and bad at, walks the classical substitution and transposition ciphers an examiner still meets in CTF-style steganography casework, names the key types and lifecycle phases that show up in PKI evidence, and closes with the attack taxonomy and Indian PKI frame. The companion topics for symmetric algorithm internals, PKI and signatures and cryptanalysis and Diffie-Hellman build on this vocabulary.
Four properties. Pick the ones the case needs and check that the algorithm delivers them.
Cryptography is not "making things secret." Secrecy is one of four properties, and confusing them in a forensic report is how an expert witness gets discredited.
The reason these are kept separate is that a single primitive rarely covers all four. Encrypting a file with AES-CBC gives confidentiality and nothing else: an attacker who flips a ciphertext bit produces a plaintext with the corresponding bit flipped (plus a 16-byte block of garbage) and the recipient cannot tell. Padding-oracle attacks against AES-CBC-only systems exploit precisely this gap. Wrapping the same payload in AES-GCM gives confidentiality plus integrity plus authentication; adding an RSA or Ed25519 signature on top gives non-repudiation.
Symmetric is fast and small. Asymmetric is slow but solves the problem nobody else can.
The two families of cryptography exist because each fixes a different problem.
| Property | Symmetric | Asymmetric |
|---|---|---|
| Keys | One shared secret per pair | Public key (open) + private key (secret) per party |
| Throughput | AES-NI: 5 to 10 GB/s on a modern CPU core | RSA-2048: ~1000 sign/s, ~25000 verify/s per core |
| Key size for ~128-bit security | 128-bit AES | 3072-bit RSA or 256-bit ECC |
| Use case | Bulk data encryption, full-disk encryption, session traffic | Key exchange, digital signatures, certificate issuance |
| Key distribution | Hard: needs a prior secure channel for the shared key | Easy: the public key can be published openly |
| Scaling for N parties | N(N-1)/2 keys for pairwise | N key pairs total |
The pre-Shannon toolkit. Worth knowing because it still shows up in CTFs and in some legacy malware C2 channels.
Modern cryptography post-dates 1949. Classical cryptography is the 4000 years before that. An examiner runs into these schemes in three places: capture-the-flag forensic challenges (NFSU and CDAC training pipelines lean on these), low-effort obfuscation in malware configuration blobs, and historical case material. Knowing how they fall apart under frequency analysis is part of the working syllabus.
Substitution ciphers replace each plaintext symbol with a different ciphertext symbol according to some rule.
Transposition ciphers keep the symbols and rearrange their order. Frequency of individual letters is unchanged, so single-letter frequency analysis fails. Bigram and trigram analysis still work.
Crypto fails at key management, not at math. Know the names.
A forensic examiner reading a system's key inventory needs vocabulary for what they are looking at.
| Key type | Asymmetry | Lifetime | Typical use |
|---|---|---|---|
| Public key | Half of a pair | Long (years, certificate-bound) | Encrypt to recipient; verify signature |
| Private key | Half of a pair | Long (years, must be guarded) | Decrypt to self; sign on own behalf |
| Symmetric key (shared secret) | Same for both parties | Variable | Bulk encryption between two endpoints |
| Session key (ephemeral) | Symmetric, derived per session | Short (minutes to hours) | TLS record layer, IPsec SA, WhatsApp double-ratchet message keys |
| Master key | Either family | Long; not used directly |
Shannon, 1949. The vocabulary every cipher designer still uses.
Three structural properties separate a serious cipher from a toy.
Strong vs weak keys. Some keys produce statistically inferior ciphertext for structural reasons in the algorithm. DES famously has four "weak keys" where encryption equals decryption (the round subkeys end up identical), plus 12 semi-weak keys with similar pathologies. AES has no known weak keys. Examiner takeaway: when reviewing a custom or legacy cipher in malware analysis, the absence of a documented weak-key analysis is a red flag.
Forward secrecy. A property of a key-exchange protocol, not of a cipher. A protocol has forward secrecy (also called Perfect Forward Secrecy when the ephemeral exchange is on a fresh group element per session) if compromise of a long-term key today does not allow decryption of past captured sessions. The mechanism is to use ephemeral Diffie-Hellman or ECDH for session-key agreement and discard the ephemeral key immediately after use. The long-term key signs the ephemeral exchange but does not decrypt the data, so its later capture cannot retroactively unlock anything.
The forensic implication for intercepted-traffic cases under Indian Telegraph Act warrants: if the traffic was captured under TLS 1.2 without PFS (RSA key exchange), the server's private RSA key, if later obtained, retroactively decrypts the entire session. If the same traffic was captured under TLS 1.3 (which mandates ECDHE), the server's long-term key is useless for retrospective decryption. The same applies to WhatsApp's double ratchet, where each message has its own derived key and even endpoint compromise reveals only future messages, not past ones.
Six attacker models, from weakest to strongest. Every protocol is rated against the worst it can survive.
Cryptanalysis is rated by what the attacker is assumed to know and can do. From hardest (least powerful attacker) to easiest:
| Attack model | Attacker capability | Hardness for attacker |
|---|---|---|
| Ciphertext-only (COA) | Sees only ciphertexts | Hardest |
| Known-plaintext (KPA) | Holds matched plaintext / ciphertext pairs | Harder |
| Chosen-plaintext (CPA) | Can submit plaintexts to an encryption oracle | Medium |
| Chosen-ciphertext (CCA1) | Can submit ciphertexts to a decryption oracle, before seeing the target | Easier |
| Adaptive chosen-ciphertext (CCA2) | Can submit ciphertexts adaptively, even after seeing the target | Easiest |
| Side-channel | Observes timing, power, EM, cache, sound from a real implementation | Sometimes trivial |
The two asymmetric primitives that built the modern internet, briefly, plus how Indian PKI uses them.
A full treatment of Diffie-Hellman and its attacks is in Cryptanalysis, Cryptographic Attacks and Diffie-Hellman. The summary an examiner needs at this level:
Diffie-Hellman key exchange (1976). Alice and Bob agree on a prime p and a generator g, public to all. Alice picks a secret integer a and publishes A = g^a mod p. Bob picks a secret b and publishes B = g^b mod p. Each computes the shared secret as B^a mod p = A^b mod p = g^(ab) mod p. An eavesdropper sees A and B but cannot extract a or b without solving the discrete logarithm problem, which is computationally infeasible for properly sized p (2048 bits or more) or for elliptic-curve variants at 256-bit. ECDH (over Curve25519, P-256, P-384) is the modern variant used in TLS 1.3, Signal, WireGuard and the WhatsApp double ratchet.
ElGamal signature scheme (1985). A signature scheme based on the discrete-log problem. Unlike RSA signatures which are deterministic, ElGamal signatures include a fresh random value per signature, so the same message signed twice produces two different signatures. This randomness is the source of both ElGamal's strength and its operational fragility: if the random value is reused across two signatures, the private key can be extracted in closed form. DSA (Digital Signature Algorithm) is a variant; ECDSA is its elliptic-curve cousin. Bitcoin's notorious early-wallet failures and the 2010 Sony PS3 ECDSA private-key extraction both came from random-value reuse.
The Indian PKI ecosystem under CCA India binds these primitives to real infrastructure:
An Aadhaar API request encrypts the PID block with a fresh AES-256-GCM session key, wraps that session key under UIDAI's RSA-2048 public key, and signs the whole request with the AUA's signing certificate. Which CIAN property is NOT directly provided by this composition?
The forensic implication is simple. When you report that "the data was encrypted," the next question is always "and was its integrity also protected, and was the sender authenticated?" If the system used a confidentiality-only mode like AES-CBC without a MAC, the chain of evidence has a hole the defence can drive through.
The reason symmetric ciphers cannot stand alone in an open network is the key distribution problem. If Alice and Bob want to share a symmetric key, they need a prior secure channel to exchange it. The internet is not a prior secure channel. For 1000 parties wanting pairwise encryption, the symmetric approach demands 1000 times 999 over 2 (which is 499,500) distinct keys, each distributed out of band. The arithmetic gets unmanageable past a handful of parties.
Asymmetric crypto solves this. Each party generates one key pair, publishes the public half (in a certificate signed by a trusted CA) and keeps the private half. Any other party can encrypt to them or verify their signature using only the public key. The total key material to manage is N pairs, not N(N-1)/2 secrets.
The cost is speed. RSA-2048 decryption is about 100,000 times slower than AES-256 on the same hardware. ECC is faster than RSA at equivalent security but still orders of magnitude slower than symmetric work. So no real-world system uses asymmetric crypto to encrypt bulk data. Every modern protocol is a hybrid system:
The TLS 1.3 handshake is the canonical instance: ECDHE for key exchange, an RSA or ECDSA signature on the handshake, and AES-GCM or ChaCha20-Poly1305 for the record layer. UPI, BHIM, and the Aadhaar API stack all follow this hybrid pattern. For Indian casework, when a witness statement says "the traffic was encrypted with RSA-2048," the technically accurate version is almost always "RSA-2048 wrapped a one-time AES-256 session key, and the actual payload used AES-256."
The one-time pad sits in a category by itself. The key is a random bitstring at least as long as the message, used once and then destroyed. If those conditions hold, Shannon proved in 1949 that the ciphertext is information-theoretically secure: a brute force over all keys produces every possible plaintext of that length, so the ciphertext reveals nothing beyond its length. The pad is unbreakable. It is also unusable at scale, because the key-management problem is exactly the message-distribution problem it was supposed to solve. The Indian PKI ecosystem under CCA does not use one-time pads; it uses computationally secure primitives because the operational tradeoff is overwhelmingly in their favour.
| Input to a KDF that produces working keys |
| Derived key | Symmetric, KDF output | Bound to master and context | Per-purpose keys from one master via HKDF / PBKDF2 / Argon2 |
The two key-derivation function families an examiner sees regularly:
The key lifecycle has five phases:
CCA India's licensing of certifying authorities (e-Mudhra, Sify, NSDL e-Governance, IDRBT, Capricorn, (n)Code Solutions, NIC) mandates audited HSM-based key generation and storage for all class-3 signing keys used on Indian Aadhaar-eSign and DSC infrastructure. The audit trail follows exactly the five-phase lifecycle above and is part of what makes an Indian DSC admissible under IT Act 2000 Section 5.
The other attack categories an examiner names:
For Indian PKI specifically, NCRB's 2024 hash-evidence guidelines treat the cryptographic primitives as out of scope for cross-examination (SHA-256 and AES-256 are accepted as forensically sound) and concentrate the examiner's testimony on key-handling, audit trail and chain-of-custody questions, which is where real cases actually fail.
A forensic examiner reading an Indian eSign audit log or a UPI dispute file needs to translate "RSA-2048 signature over the AES-256 wrapped session key" into the CIAN-checklist language of Section 1, prove each property held at the right phase, and identify which key in the lifecycle was used at each step. This is the foundation; Symmetric Cryptosystems: DES, AES, RC4 and Blowfish and Asymmetric Cryptosystems, Hashing, PKI and Digital Signatures build on it.