Cyber Security: Cryptography and identity

A salt is a random value, unique to each account, that is combined with the password before it is passed through a one-way hash function; both the salt and the resulting hash are stored. If two users choose the same password, their stored hashes still differ, and an attacker who steals the database cannot use a ready-made 'rainbow table' of common passwords and their hashes but must attack every password separately. NIST SP 800-63B requires passwords to be salted and hashed with a suitable password-hashing scheme. Encryption that can be reversed is the wrong tool, because sites should never be able to recover a password; they verify it by hashing the entered value again and comparing.

The Controller of Certifying Authorities (CCA), set up under section 17 of the IT Act on 1 November 2000 within the IT ministry, operates the Root Certifying Authority of India. Section 18(b) gives the Controller the function of 'certifying public keys of the Certifying Authorities'; the RCAI's own root certificate is self-signed and forms the top of India's PKI. Licensed CAs (for example eMudhra and IDRBT's CA for the banking sector) then issue Digital Signature Certificates to individuals and organisations. The CCA also lays down standards for CAs, supervises them and empanels eSign service providers. CERT-In handles incident response, RBI regulates banking and IDRBT, a banking technology institute, is itself one of the licensed CAs, not the root.

All three statements are correct. Section 3 of the IT Act says authentication of an electronic record 'shall be effected by the use of asymmetric crypto system and hash function', and section 3(3) adds that 'any person by the use of a public key of the subscriber can verify the electronic record'; the private and public keys form a unique functioning key pair. The Act also defines the hash function as one that always gives the same result for the same input and makes it computationally infeasible to reconstruct the record or to find two records with the same result. The IT (Amendment) Act 2008 inserted section 3A (in force from 27 October 2009), which made the law technology-neutral by allowing any reliable 'electronic signature' technique notified in the Second Schedule, alongside digital signatures.

Statements 1 and 3 are correct. Two different goals need two different keys. For confidentiality, the sender locks the data with the recipient's public key; only the recipient's private key can unlock it, so even Anita cannot decrypt the file once it is encrypted. For authenticity, the sender signs with her own private key, which only she holds, and anyone can verify with her public key; this is exactly how section 3 of the IT Act describes verification 'by the use of a public key of the subscriber'. Statement 2 is wrong: a signature made with a public key would prove nothing, because the public key is known to everyone. In practice, the file is encrypted with a random symmetric key, and only that key is wrapped with Bharat's public key.

In TLS (the current version is TLS 1.3, RFC 8446), the handshake does two jobs with public-key cryptography. First, the server proves its identity by presenting a certificate signed by a trusted Certifying Authority and by signing handshake data with its private key. Second, the two sides run a key exchange (typically elliptic-curve Diffie-Hellman) to derive shared secret keys. From then on, the actual traffic is protected by a fast symmetric authenticated cipher such as AES-GCM. TLS does not compress pages for speed, and it does not hide the user's IP address from the site; anonymity needs other tools such as Tor, and even a VPN only shifts trust to the VPN operator.

Statements 1 and 2 are correct. Symmetric ciphers use one shared secret key; AES, standardised by NIST in FIPS 197 (2001), is the best-known example and works on 128-bit blocks with 128, 192 or 256-bit keys. Asymmetric cryptography, introduced publicly by Diffie and Hellman in 1976 and made practical by RSA, uses a mathematically linked key pair: what one key locks, only the other can unlock, so the public key can be shared openly. Statement 3 reverses the truth. Public-key operations are far slower, so real systems such as HTTPS use a hybrid design: public-key methods authenticate the parties and agree a session key, and a fast symmetric cipher then encrypts the bulk data.

Statements 1 and 2 are correct. A digital certificate (in practice an X.509 certificate) contains the holder's name or domain, the holder's public key, a validity period, the issuer's name and the issuer's signature over all this data. Anyone who trusts the issuer can check that signature and so trust that the key belongs to the named holder. In India, section 18(b) of the IT Act lists 'certifying public keys of the Certifying Authorities' among the Controller's functions, which the CCA performs through the Root Certifying Authority of India. Statement 3 is wrong and dangerous: the private key never goes into a certificate. It stays secret with the holder (on a USB token, smart card or secure hardware), and a signature is checked with the public key.

Statements 1 and 2 are correct. A valid certificate proves control of a domain name, not good intent. The FBI's public service announcement of 10 June 2019 warned that phishers increasingly obtain free certificates so that fake sites show HTTPS and the padlock, and told users not to trust a site just because of them. Certificates carry 'not before' and 'not after' dates, and a CA can revoke a certificate early, publishing it in a certificate revocation list (CRL) or through online status checks, if the key is stolen or the details are wrong. Statement 3 is false: a self-signed certificate is signed by its own key, so it guarantees integrity but not authenticity (NIST); browsers show a warning unless the user or an organisation installs it as trusted.

All three must report cyber incidents (d). Under Section 70B of the IT Act, 2000 and the CERT-In Rules, 2013, service providers (1), data centres (2), body corporates (3) and intermediaries must report cyber security incidents to CERT-In (the Indian Computer Emergency Response Team, under MeitY). CERT-In's April 2022 directions set a six-hour reporting deadline. They also require logs to be kept for 180 days, and VPN providers must store user details for five years.

Critical sectors are protected by NCIIPC under Section 70A. Notice the related laws: the Digital Personal Data Protection Act, 2023 and its 2025 Rules, which add a duty to report data breaches to the Data Protection Board.

Answer as per the official UPSC answer key.

Open this question's page →