Possible to read strength of encryption?

Question

With the recent talks of governments trying to weaken encryption, I had a question about how they would implement it.

For example, let's just say that the government banned anything above AES-128. I know AES-128 is still "uncrackable" at this point in time, but for the sake of argument let's say that's what they decided to do.

Is it possible for someone in the middle of an encrypted channel to tell the size/strength of encryption used? So basically, would the government be able to tell you are using too strong of encryption just by recording the data sent between two endpoints?

Thanks

Answer 1

Is it possible for someone in the middle of an encrypted channel to tell the size/strength of encryption used?

In a well-designed algorithm, encrypted data should be indistinguishable from random noise. Some formats normally have header fields. e.g., PGP in asymmetric mode will tell you what the intended asymmetric key id is and the intended symmetric algorithm will be encrypted with that key. I'm unsure what header is output in symmetric mode. Zip files will specify algorithm and bit size clearly in the header. 0x66(0E|0F|10) map to AES(128|192|256). The spec does allow setting the field to 0xFFFF for "unknown algorithm".

Thus, the answer is entirely implementation dependent. Without specifying a header, it should be impossible to determine algorithm and bit length without decrypting the contents through brute force.

Answer 2

I am afraid that it is rather easier to enforce it by the power of law and policing than technically.

What I mean is: They can outlaw the strong encryption and then just just punish anyone who uses it. Say you still use it but if they try to decipher it and fail, you are responsible for that (spending time in jail).

It is kind of similar of what they have in UK - you can use encryption but failing to decrypt by the court order is against the law and punishable by jail time (IANAL, please correct me if I am wrong).

I don't think it will take much time, after a series of loud court processes and a couple of people put to jail, until most of the population will stop using it (I mean private persons). I think that companies will implement backdoors or weak encryption as soon as the law is passed since noone would want to risk profits for their users (maybe with the exception of some companies who will just close their business).

Answer 3

If you start observing an encrypted channel in the middle, it pretty much looks like just a bunch of bytes. Symmetric encryption algorithms produce encrypted streams that are practically indistinguishable from random streams if you don't know the key. Observations may reveal the algorithm's block size, if any, by measuring the packet sizes — for a block cipher, network packets are more likely to contain whole blocks. But the block size doesn't say much about the algorithm strength; for example all AES key sizes use the same block size (16 bytes).

But observing encrypted channels from the middle only isn't very realistic: usually, an eavesdropper can start watching from the beginning. While it is possible to devise protocols that obscure the choice of algorithm to an eavesdropper, it is somewhat impractical and, in fact, counterindicated: such a protocol doesn't scale well. In practice, protocols tend to have variants, for example allowing different suites of cryptographic algorithms. Hard-coding cryptographic algorithms is bad design because algorithms can be broken or weakened — it's rare, but it happens: MD5 is thoroughly discredited for most uses, SHA-1 is considered somewhat deprecated today. More commonly than cryptographic primitives, cipher suites can have weaknesses due to design or implementation mistakes: witness attacks on TLS such as BEAST or the attacks on RC4. Supporting multiple algorithms allows reacting quickly to such attacks, without having to arrange for every participant to upgrade their software at the same time.

If the software supports multiple algorithms, then there needs to be some form of negociation between participants so that they agree on which one to use. That negociation takes place before the two parties have agreed on a way to encrypt information, so at least part of the negociation has to happen in cleartext. You need to negociate before you can encrypt, and the negociation of how to encrypt can't be encrypted.

You could do a two-phase negociation, where the parties first agree on a cipher suite to perform an encrypted negociation to agree on the cipher suite for regular communication; but that's rather convoluted for a very limited benefit.

Answer 4

I feel like this is a silly answer to your question, but I can't find a flaw in my logic, so I'm going to let it fly:

The only sensible reason I can think of for a government to limit the strength of encryption, is if they can break it at or below the limit, but cannot necessarily do so above the limit. If that's the case, then they could simply try to decrypt it. If they don't succeed, then they would know the encryption level is either over the limit, or is just random data. Either way, that could be enough to raise a flag.