Module 7 · Social Media Forensics & Cryptography
Asymmetric Cryptosystems, Hashing, PKI and Digital Signatures
RSA, ECC, SHA-2/3, HMAC, X.509 and the Indian CCA PKI stack with Class 3 DSC and UPI cryptography.
Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
RSA, ECC, SHA-2/3, HMAC, X.509 and the Indian CCA PKI stack with Class 3 DSC and UPI cryptography.
A forensic examiner is never the cryptographer who designs the cipher, but is regularly the person who has to read a TLS handshake out of a packet capture, verify a Section 63 BSA hash chain, or open a .p7s signed email and explain to a court why the signature is valid. That requires a working grasp of asymmetric cryptography (the maths that lets a stranger encrypt to you without sharing a key), of hashing (the one-way fingerprint that anchors evidence integrity), and of the PKI plumbing that ties a public key to a real person on a real Aadhaar-verified registration. The Indian dimension is concrete: the Controller of Certifying Authorities (CCA) under MeitY licenses every CA that can issue a legally usable Digital Signature Certificate, and IT Act 2000 Section 35 is the statutory hook that makes a DSC a recognised signature in income tax filings, GST returns, MCA filings and GeM tenders.
This topic walks the maths just far enough to make standard textbook questions answerable, then spends most of the time on what an examiner actually sees on the wire and in evidence: RSA-OAEP versus the broken PKCS#1 v1.5, SHA-256 versus the dead SHA-1, X.509 chains, Class 3 DSC tokens on a USB cryptographic device, and the way TLS combines an asymmetric handshake with an AES-GCM bulk channel. UPI's cryptographic backbone gets a short tour because it is the most visible Indian deployment of the same primitives. By the end the reader should be able to read a certificate, write a sane hash policy and recognise the failure modes that show up in real Indian cases.
One key locks, a different key unlocks.
Symmetric cryptography works when both parties already share a secret. Asymmetric cryptography solves the problem when they do not. The construction depends on a mathematical operation that is easy in one direction and hard in the other unless you hold a small piece of secret information. Multiplying two 1024-bit primes is fast; factoring the 2048-bit product back into those primes is infeasible on classical hardware. Adding two points on an elliptic curve is fast; recovering the scalar that produced a given point from a base point is infeasible. These are the trapdoor functions that every public-key scheme rests on.
The practical consequence is a key pair. The public half is published, embedded in a certificate or printed on a smart card; anyone can encrypt to it or verify a signature against it. The private half stays on a hardware token, in a software keystore, or inside an HSM. The mathematical structure guarantees that the public half cannot be derived from anything an attacker can see on the wire. Whether that guarantee holds depends entirely on the maths staying hard, on the implementation being correct, and on the random-number generator being honest.
| Property | Symmetric (AES, ChaCha20) | Asymmetric (RSA, ECC) |
|---|---|---|
| Key model | One shared secret key |
Two primes, a public exponent, a modular inverse and a worked round.
RSA is the first public-key system that became mainstream and the one every Indian PKI question still revolves around. The construction is small enough to set out in full and the algebra is approachable.
Smaller keys, the same guarantees, a different hard problem.
DSA (FIPS 186) is a digital signature algorithm built on the discrete logarithm problem in a finite field, not on factorisation. It only signs; it does not encrypt. Classical DSA used 1024-bit primes and has been progressively retired in favour of ECDSA, which moves the same maths into the elliptic-curve world. The advantage is dramatic: a 256-bit ECDSA key offers security comparable to a 3072-bit RSA key, with signatures about a tenth of the size and verification several times faster.
Elliptic curves are named, and the names matter on the wire and in standard textbook questions. The NIST curves P-256, P-384 and P-521 are the workhorses in Indian PKI and CCA interoperability lists. Curve25519, designed by Daniel Bernstein, is the underpinning for X25519 key exchange and Ed25519 signatures; it appears in SSH, Signal, WireGuard and a growing fraction of TLS handshakes. The curve secp256k1 is the Bitcoin and Ethereum curve and shows up in blockchain forensics rather than in document-signing contexts.
| Algorithm | Hard problem | Typical key size | Use case |
|---|---|---|---|
| RSA | Integer factorisation | 2048 or 3072-bit | Encryption (OAEP) and signatures (PSS); legacy default for Indian DSC |
| DSA | Discrete log in finite field | 1024-3072-bit prime | Signatures only; largely retired in favour of ECDSA |
| ECDSA on P-256 |
The fingerprint that anchors every Section 63 BSA hash chain.
A cryptographic hash maps an input of any length to a fixed-length digest. The defining properties are pre-image resistance (given a digest, finding any input that produces it is infeasible), second pre-image resistance (given an input and its digest, finding a different input with the same digest is infeasible), and collision resistance (finding any two inputs with the same digest is infeasible). The avalanche effect describes the empirical behaviour that flipping one input bit changes about half the output bits.
The history of hash functions is the history of those properties breaking. MD5 (128-bit, Rivest 1992) fell to Wang's collision attack in 2004 and is now trivially collidable on a laptop. SHA-1 (160-bit, NIST 1995) was deprecated by NIST in 2011 and was broken in practice in 2017 by the SHAttered attack from Google and CWI Amsterdam, which produced two distinct PDF files with the same SHA-1 digest at a cost of about 6500 CPU-years. SHA-2 (the family with SHA-256, SHA-384 and SHA-512) is the current workhorse and remains unbroken. SHA-3, standardised by NIST in 2015 as FIPS 202, uses a completely different sponge-function construction and provides an alternative if a structural weakness is ever found in SHA-2.
| Hash function | Year | Digest size | Status in 2026 |
|---|---|---|---|
| MD5 | 1992 | 128-bit | Broken; collisions in seconds. Forbidden in new work; persists only in legacy interop. |
| SHA-1 | 1995 | 160-bit | Broken (SHAttered 2017). NIST deprecated 2011. Forbidden in TLS and code signing. |
From a private key on a USB token to a courtroom-grade signature.
A digital signature proves three things at once: that the signer holds the private key paired with a known public key, that the signed bytes have not been changed since signing, and that the signer cannot later deny producing the signature. The construction is simple. Hash the message with SHA-256 (or stronger). Sign the hash with the private key using RSA-PSS, ECDSA or Ed25519. The signature is appended to the message or carried in a separate envelope (PKCS#7, CMS, XAdES, PAdES depending on context).
Verification is the reverse. The recipient hashes the received message, decrypts the signature with the signer's public key, and compares. The two values match if and only if the signer's private key signed exactly those bytes and the message has not been tampered with. The hash function and the asymmetric algorithm are both load-bearing; using SHA-1 with RSA-PSS in 2026 is broken in spirit even though many PDF signing tools still accept it.
Asymmetric to bootstrap, symmetric to carry the traffic.
No production system encrypts large messages with RSA. The cost is too high and the construction is too brittle. Every modern protocol uses hybrid encryption: an asymmetric step establishes a per-session symmetric key, and the bulk traffic runs under an AEAD symmetric cipher like AES-GCM or ChaCha20-Poly1305. TLS, IPSec, SSH, Signal, S/MIME and UPI all follow this pattern, with variations.
Which padding scheme is the current standard for RSA encryption after Bleichenbacher's attack on PKCS#1 v1.5?
| Public + private key pair |
| Speed | Fast: AES-NI gives GB/s on commodity CPUs | Slow: RSA-2048 sign is ~1-2 ms on a modern CPU |
| Typical use | Bulk data encryption inside an established session | Key establishment, digital signatures, certificate hierarchies |
| Key size at 128-bit security | AES-128 (16 bytes) | RSA-3072 (384 bytes) or ECC-256 (32 bytes) |
| Hard problem | Best attack ~ brute force on the key | Integer factorisation (RSA) or discrete log (DH, ECC) |
The Indian anchor for this section sits one level up the stack. The CCA India publishes interoperability guidelines for licensed CAs that pin acceptable algorithms and key sizes: RSA at 2048 bits is the minimum for a Class 3 DSC issued today, with eMudhra, Sify, Capricorn CA and IDRBT all aligned to that floor. The maths does not change at the border, but the policy does.
Two practical points an examiner must hold on to. First, textbook RSA (encrypt m as m^e mod n directly) is malleable and leaks information; every real deployment uses padding. PKCS#1 v1.5 padding is the older form and is broken in the encryption context by Bleichenbacher's adaptive chosen-ciphertext attack (1998), which is why every modern TLS deployment uses RSA-OAEP for encryption and RSA-PSS for signatures. Second, key size guidance has moved. NIST SP 800-57 treats 2048-bit RSA as acceptable up to about 2030; 3072-bit is the recommended floor for use beyond 2030; 4096-bit is the conservative choice for long-lived signing keys. India's CCA interoperability guidelines track this trajectory and the next generation of Indian DSC issuance is expected to ride 3072-bit RSA or ECDSA on a NIST curve.
| Elliptic curve discrete log |
| 256-bit |
| Signatures in TLS, code signing, modern DSC roadmaps |
| Ed25519 | Edwards-curve discrete log | 256-bit | Fast deterministic signatures; SSH, Signal, WireGuard, OpenPGP |
| ECDH / X25519 | Elliptic curve Diffie-Hellman | 256-bit | Key exchange in TLS 1.3 and IPSec |
The Indian anchor here is the IDRBT roadmap. The Institute for Development and Research in Banking Technology operates the IDRBT CA, which is one of the CCA-licensed CAs serving the banking sector, and its published roadmap moves new bank-grade certificates to ECDSA on NIST P-256 and P-384 in parallel with continued RSA-3072 issuance. UPI's own message-level cryptography continues to rely on RSA-2048 with SHA-256 for backward compatibility with the long tail of bank gateways.
| SHA-256 / SHA-512 (SHA-2) | 2001 | 256 / 512-bit | Current workhorse. The hash of choice for Section 63 BSA chains, TLS, code signing. |
| SHA-3-256 / -512 | 2015 | 256 / 512-bit | Standardised alternative based on Keccak sponge construction. Drop-in if SHA-2 is ever weakened. |
| BLAKE3 | 2020 | 256-bit (variable) | Very fast in software; common in build systems and Git replacements; rare in legal-grade evidence. |
HMAC (Hash-based Message Authentication Code, RFC 2104) is the construction that turns a hash function into a keyed MAC. The naive approach (compute SHA-256 of key concatenated with message) is broken by the length-extension attack against SHA-2; HMAC uses a specific double-hashing structure that is provably immune. Whenever an authentication tag is needed using a hash function (in API request signing, in TLS pre-1.3 MACs, in token verification), HMAC is what to reach for.
Password storage is a separate problem because the input has low entropy. Plain SHA-256 of a password is a disaster because a GPU can try billions per second. The right primitives are slow and memory-hard by design: bcrypt (Provos and Mazieres 1999, used widely), scrypt (Percival 2009), and Argon2 (Biryukov et al, Password Hashing Competition winner 2015). Argon2id is the recommended choice for new applications. Indian banking gateways have steadily moved from MD5 and SHA-1 password hashing through bcrypt to Argon2 in their newer systems.
Fuzzy hashing is a different beast useful in malware investigations. ssdeep computes context-triggered piecewise hashes that detect near-duplicates; TLSH (Trend Micro Locality Sensitive Hash) does similar work with better robustness on small files. These are not cryptographic hashes, do not satisfy collision resistance, and are not used as evidence integrity anchors; they are triage tools that cluster similar samples for review.
X.509 is the certificate format that carries the binding between a public key and an identity. Every certificate contains the subject (the identity), the issuer (the CA that signed it), the public key, a validity period, a serial number, key usage extensions (digital signature, key encipherment, code signing) and the CA's signature over the whole structure. The recipient walks up the chain from the leaf certificate to a trusted root, verifying the signature at each step. If any signature in the chain fails to verify, or any certificate has been revoked or expired, the chain is broken.
Revocation is the operational pain point. Two mechanisms exist. A Certificate Revocation List (CRL) is a signed list of revoked serial numbers, published periodically by the CA; the client downloads and consults it. OCSP (Online Certificate Status Protocol) is a real-time query to the CA's responder asking whether a specific certificate is still valid. OCSP stapling lets the server fetch its own OCSP response and attach it to the TLS handshake, sparing the client a round-trip. CCA-licensed Indian CAs publish CRLs and run OCSP responders; a forensic examiner who is challenging or supporting a digital signature must check both.
UPI uses the same primitives in a different envelope. Every UPI message between a payer's PSP app, the NPCI switch and the payee's PSP travels under TLS, but the message itself also carries application-layer cryptography. The payer's device generates a transaction message, the PSP signs it with an RSA-2048 key, the message is hashed with SHA-256 and encrypted to NPCI's public key, and AES-256 is used for any payload-level sealing. The PIN itself is captured by NPCI's Common Library (CL) running in the PSP app, encrypted on-device with a per-transaction key derived from the device fingerprint, and never seen in plaintext by the PSP. The whole stack is RSA-2048 plus AES-256 plus SHA-256, and it has held up in volume.
| Stack | Asymmetric step | Symmetric step | Hash |
|---|---|---|---|
| TLS 1.3 to a bank portal | ECDHE-X25519 + RSA-PSS or ECDSA server signature | AES-128-GCM or ChaCha20-Poly1305 | SHA-256 in the transcript |
| UPI message to NPCI | RSA-2048 PSP signing key + NPCI public key | AES-256 for payload sealing | SHA-256 over the message |
| Signal direct message | X25519 + Ed25519 (XEdDSA) | AES-256-CBC + HMAC-SHA-256 (Double Ratchet) | SHA-256 in the ratchet |
| S/MIME signed email (`.p7s`) | RSA-2048 or ECDSA P-256 | Not used for signing-only | SHA-256 in the signed-attrs |
| Class 3 DSC signed PDF (PAdES-B) | RSA-2048 or RSA-3072 from a CCA-licensed CA | Not used for signing-only | SHA-256 over the document range |
The forensic consequence is that an examiner asked to analyse a TLS capture or a signed PDF needs to be able to identify each layer: which curve was used, which cipher suite was negotiated, which hash was specified, which certificate chain ended at which Indian CA. Tools like Wireshark, openssl, sslyze and the Adobe Acrobat signature panel expose these fields directly. Cross-link with Symmetric Cryptosystems: DES, AES, RC4, Blowfish for the AES-GCM side of the picture and with Cryptanalysis, Cryptographic Attacks and Diffie-Hellman for the ECDHE and PFS detail.