Someone Says 40-Bit Encryption Is Illegal in India

Somebody in a forum claims that encryption beyond a certain bit count is illegal in India, and the thread beneath it contains three different numbers. The claim arrives as a deployment constraint long before it arrives as a citation, and obeying it means weakening an SSH or VPN profile to fit a figure nobody can source. Turn that around: the document comes first, and the number is whatever the document turns out to say. This page is a reading method, not a determination about your connection. It says what to fetch, what to write down, and when to hand the question to a lawyer.

Ask for the document, not the number

Three kinds of text can produce a restriction and they are not interchangeable: an Act, an instrument made under it, and a licence condition attached to a named service. Each has its own addressees, scope and version. When somebody cites a limit, ask which of the three they mean and get the file, because a summary that has lost that distinction cannot be checked against anything. The India Code copy of the Information Technology Act, 2000 is a reasonable starting point rather than the answer.

A figure with no document behind it is a rumour that has learned to sound technical. Asking for the file costs one message; downgrading a working tunnel to match the rumour costs a security change nobody can justify afterwards.

Read the section you were handed

Take section 84A in that PDF. On its printed page it gives the Central Government power to prescribe modes or methods for encryption, and it says nothing about 40, 128 or 256 bits. That is what an enabling provision looks like: it authorises rules instead of stating them. Reading the page settles what the section does and, just as usefully, what it does not do.

The absence of a number there is not evidence of absence everywhere. A different section, a notification or a licence may say something else, and only that text can be read to find out.

An enabling power is not the operative rule

Powers and rules live in different documents, and that difference decides whether a claim can be checked at all. If the limit supposedly comes from a licence, read the licence; if from a notification, read the notification and its date; if from the Act, read the section and the subsection. Swapping one for another is the most common error in these threads, and it is invisible once the summary has been repeated a few times. Note which version you read and when that copy was published.

File metadata is a hint about the copy in your hand, not proof that the text has not moved since. A 2018 download date says nothing about 2026.

Write your own role down before judging the claim

Scenarios, not slogans: describe in three lines what you would actually do. A traveller using an approved corporate tunnel, an administrator running a private server for a small team, and a provider selling access to strangers are three different descriptions with three different legal surfaces. A conclusion drawn about one of them does not travel to the others, because the definitions and addressees in the instrument may not cover the same people. Write the description first, then go looking for the rule that applies to it.

Then collect the two facts a lawyer would need. For a licensing claim: who holds the licence, and which service does it cover? For a software claim: which conduct is restricted, holding it, supplying it, running it, or one named use?

Make the question precise enough to answer

Two more things belong in the request. First, what the quoted number actually measures, because an SSH session has host keys, user authentication keys, key exchange and symmetric traffic, and a bare bit count names none of them. Second, which document and version the claim rests on, with the exact clause if there is one. Add your activity, locations, parties and configuration, and the request becomes something counsel can answer instead of a debate.

Wording decides outcomes here. Section 69 of the same Act deals with interception, monitoring and decryption directions under specified authority and recorded reasons, which is not the same as an instruction to hand a password to anyone claiming official status. Reading the conditions is the whole difference.