Asymmetric Cryptosystems, Hashing, PKI and Digital Signatures

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.

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.

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.

1. Pick two large primes
   Choose primes p and q of roughly equal bit length. For RSA-2048, each prime is about 1024 bits. The randomness here matters: a weak RNG that produces a predictable p ruins the whole scheme.
2. Compute the modulus
   n = p * q. This n is the public modulus. Its bit length is the 'key size' people quote (2048, 3072, 4096).
3. Compute Euler's totient
   phi(n) = (p - 1) * (q - 1). This stays secret because it is equivalent to knowing the factorisation.
4. Pick the public exponent
   e is a small odd integer coprime to phi(n). Almost every modern deployment picks e = 65537 (2^16 + 1) because it is small enough for fast verification and large enough to resist low-exponent attacks.
5. Compute the private exponent
   d is the modular inverse of e mod phi(n): e * d is congruent to 1 mod phi(n). Computed with the extended Euclidean algorithm.
6. Publish and protect
   Public key: (n, e). Private key: d (plus p, q, phi(n) for performance via the Chinese Remainder Theorem). The private key never leaves the token or HSM.

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.

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.

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.

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.

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 unsuitable because a GPU can try billions of candidates per second against a static digest. 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 serves a different purpose, 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.

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.

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, eliminating the client round-trip to the CA responder. CCA-licensed Indian CAs publish CRLs and run OCSP responders; a forensic examiner who is challenging or supporting a digital signature must check both.

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.

1. Client hello
   The client opens with a TLS ClientHello listing supported cipher suites, the highest TLS version it supports, a random nonce, and (in TLS 1.3) a key_share with an X25519 or P-256 ephemeral public key.
2. Server hello and certificate
   The server picks a cipher suite, returns its X.509 certificate chain, and contributes its own ephemeral key_share. In TLS 1.3 this is one round trip; in TLS 1.2 it took two.
3. ECDHE key agreement
   Both sides compute the shared secret from their ephemeral private key and the other side's public key. This Diffie-Hellman step delivers Perfect Forward Secrecy: even if the server's RSA or ECDSA private key is later compromised, recorded traffic stays unreadable.
4. Server signature
   The server signs the handshake transcript with its long-term private key (RSA-PSS or ECDSA) so the client can verify it is talking to the holder of the certificate. The signature authenticates the ECDHE exchange against a MITM.
5. Bulk encryption
   The shared secret is run through HKDF to derive AES-GCM keys for the application data. Subsequent records use AES-128-GCM or AES-256-GCM (or ChaCha20-Poly1305) for the rest of the session.

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 stack is RSA-2048 plus AES-256 plus SHA-256.

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.