Does exposing algorithm, key size and IV weaken the security?

Question

I am using an encryption program to encrypt my documents. Previously I have used PGP and AxCrypt, so I just wanted to see how this new tool encrypts the file.

This tool is keeping parameters like cipher name, key size,initialization vector etc. in plain text.

I want to know whether exposing these details can anyway help an attacker to focus his attacks.

Below are the top few lines of a sample encrypted file:

  »     ÌšÚ>Öùq¸ë®ûÑÅ#Ÿ £¦É² $Náøj_{
                "artifact":"header",
                "cipher":{
                         "algorithm":"AES",
                         "IvBytes":"c6+TSc609YSMQSeorKSwAg==",
                         "mac":{
                               "enabled":false
                               },
                         "mode":"CBC",
                         "padding":"PKCS7",
                         "keySize":256,
                         "blockSize":4096,
                         "iv":"c6+TSc609YSMQSeorKSwAg=="
                         },
                "metadata":{
                            "name":{
                                    "encrypted":false,
                                    "value":"~$$tmpFDC6.tmp.bc"
                                   }
                           },
                "version":1,
                "encryptedFileKeys":[{
                                      "type":"data",
                                      "id":"2705583903525488672",
                                      "value":"KIgNTpyr1+9QLSUijmpxh0jnfyi/6fIY2zoBzMsw2/B3WDmbV3+M2QsLbCLei++G8UDsjyjFiooXQpWJbUF75+Sg2AhhHS4YkvytSrgUW3/J56ky+a0XDti46e0I94oHAstL/BrS31NIqkCQW80qCja4nEzkRyHE5j3W8SR9nh8I2oDSONesy/BenzIUjz3IoNnYD750LKR7IA7xrJ75hT9uYZ9oZr9EKcKPR0Fwyy1dnVCaJWrstjnAYunnKw8irU70zmYxh6ytDsc3x70e7aj7rikQ7n3H4CquOyPqvIESpuGGWzlrTAvNoT8UHJuegAxWEMewOVkAYuwEcUnOIQt5YV8/B8ds+hfyAGRD4rf7GjsCExC+t69ekeDB63+s7LcmkCsZJKpiER3D3+OpYaANQxs2ceIEPPEPOrVbL98eTJa42elL29CeIkA5rmYtMhv6Nh+baH5LxOWxTrKM4n+dlnSwsd//CupGC0jWi8JNCu9MEx0o33S1TgqEGjYRSBLh/rfQu7CaYB4JxaluuqfOstb33JESaX77b1jBadwj1t977ZGKw4HK3HMcrQoJL1yjEd71uHOOX5bgKrvz1V9hrxNkT6MseeSV7N9Vf38oYAZrSz0dGemQBNpxZMwhKu9qd6Xi6V8v5Az7CcYcaEtQCc+tO7F3Vgmfv92U5WQ="
                                     }]
                }

Answer 1

No cryptography worth its salt should become less secure because its inner workings are known. It is usually assumed that the adversary has all that information when doing security proofs (Kerchoff's principle/Shannon's maxim).

In your particular case the tool is using pretty standard crypto (AES-CBC-256) so you don't need to worry about exposing its details.

As some of the other comments point out, the tool you're using seems to have disabled the MAC (message authentication code), which opens it up to attacks in which the attacker could modify the ciphertext of a given file in deterministic ways such that you would decrypt a message of his/her choosing. I would recommend you enable it.

Another thing to note about file encryption is that the ciphertext (or the AAD -Additional Authenticated Data- if you were using authenticated encryption such as GCM) should contain the filename as well. Otherwise an attacker can swap the ciphertext of a file for another one you also encrypted.

Now, you specifically ask if this helps an attacker focus his attacks. I guess the answer is yes, if there were attacks against a particular ciphersuite, knowing that it is the one being used will facilitate the attackers task. On the other hand, if the attacker can interact with the system he/she will most likely figure it out given enough time. Or they could just throw all known attacks at it. In summary, there is nothing to gain by hiding this type of information.

Answer 2

This is a touchy subject for cryptographers. The party line is "you should be able to reveal everything except the keys without decreasing the security of your system." If you assume this party line, you'll generally be well received by the cryptography community. However, the real answer is more murky.

The real answer is that revealing any information makes it easier to attack a cryptosystem. For a trivial example, any encryption, no matter how horridly weak, is 100% secure if the adversary cannot get their hands on the ciphertext. You never know when revealing such information might weaken your system, and giving up information is always worse than not giving up information.

That being said, those who develop cryptographic algorithms explicitly strive to minimize how much these leaks provide value to an attacker. As mentioned in the comments, Kerckhoffs’ principle states that a good cryptosystem should be secure against an attacker who knows everything about the system except the key. This is the ideal, not a statement of reality, but modern cryptosystems like AES and SHA-3 do a remarkably good job of getting close to this ideal. A large body work is dedicated to proving that each algorithm is secure against many kinds of attacks directly targeting the "weak points" of the algorithm. This body of work is so vast and thorough that the community generally just says "reveal all the information you want, other than the keys." Their algorithms are good enough to operate in such hostile environments.

There are times where one may elect to keep these details secret. One example is in the military. When the fate of your entire nation may rest on the assumption that the enemy does not know how to break your algorithm, it may be very reasonable to keep the algorithm secret. Of course, you will still want to strive towards an algorithm that fulfills Kerckhoffs’ principle anyway, so that the system is still secure after the physical devices get captured.

The story of the Enigma machine would be an excellent example of this. The Allies went to great efforts to obtain the physical machines so that they could start breaking the codes. However, on the other side of that argument, even when the physical device was finally acquired, it still took a tremendous amount of work to find exploits to break it, so as far as Kerckhoffs’ principle goes, the Enigma did quite well. This shows an example of both policies working well. The Germans kept the algorithm a secret (and thus truly unbreakable for a time), and even when the secret was revealed, the algorithm was still secure.

I think the key line between the two viewpoints is the difference between wanting to use a secure algorithm and wanting to use an algorithm that the enemy has not yet broken. Publishing the extra information (such as the algorithm and IVs) permits civilian exploration of the algorithm, theoretically making it more secure, but it comes with a tradeoff. If your adversary breaks the encryption and chooses not to tell anyone, you aren't aware that it has a weakness, and that can destroy your nation.

If you're a small fry (like the majority on this website), its better to strive to use a secure algorithm. When you start worrying about keeping the algorithm a secret from your enemies, you make the assumption that that secrecy is worth more than the value added by hundreds of trained eyes looking at your algorithm. If you're the NSA, this could actually be a good trade, because you're employing thousands of trained eyes to look at the algorithm. If you're small, it's a bad trade because you may only be able to afford a half-dozen eyes looking at the algorithm. For us small-timers, its better to rely on the community at large's opinion about the security of these algorithms, and the community at large values the kinds of algorithms that don't mind leaking anything but key information.

Answer 3

The cryptography systems have been designed in such a way that if their plain-text space, key space, key generation algorithm, encryption algorithm, decryption algorithm, cipher-text space are known, then also one should be able to securely perform desired actions.

Here, you need to first think about what kind of attack an adversary can do:

1. Chosen Cipher-text Attack
2. Chosen Plain-text Attack
3. Chosen Cipher-text Attack Adaptive(CCA2)
4. Chosen Plain-text Attack Adaptive(CPA2)

or any other. Then, try to formulate the possible leaks in the tool and possible ways to overcome them.

Answer 4

Ciphers are already designed to provide a sufficient security margin against attackers who know those details, as other answers make amply clear. But another way of looking at this question is: if you don't reveal the cipher and key size, how much harder do you make the attacker's job?

There aren't that many ciphers out there, and most people use the same few ones. The documentation for libgcrypt (used by GnuPG) lists 18 ciphers, which encompasses both cipher family and key size (AES 128 and 256 are given as two ciphers). Even if we assumed that all 18 are equally likely, the attacker's uncertainty about the cipher would only get you about 4 bits of security. At most.

Meh. I'll take the self-documenting file format instead.

---

How about hiding the IV? Well, if the attacker doesn't know the IV, they can't decrypt the message. But the recipient also needs to know the IV, so you might think that you can gain extra (but in fact unnecessary) security by hiding the IV. But there are several problems here.

First, cipher designers don't generally claim that keeping the IV secret improves security, because the ciphers are not designed to do that. People generally don't analyze whether ciphers provide extra security under these assumptions, so you'd be on your own.

Second, you'd effectively be treating the IV as part of the key (a shared secret), but in real ciphers the requirements on the key and IV are different. In particular:

1. Keys are supposed to be reusable for multiple encryptions;
2. Key + IV pairs should never be repeated for more than one encryption—otherwise confidentiality may be lost.

So you'd be foregoing the convenience of being able to reuse the same key for multiple encryptions. That's after all the point of public IVs—it's a mechanism that allows for safe key reuse by varying a non-secret value for each encryption. But because the problem IVs solve doesn't really go away, you'd end up paying the cost somewhere else, for example by:

1. Establishing a fresh key for every encryption operation. This would have a performance or convenience cost; or worse, you could do it insecurely;
2. Building the functional equivalent of IVs somewhere else in the system—which you might get wrong as well.

So making the IV a shared secret is like playing whack-a-mole—it's going to pop up somewhere else.

How about encrypting the IV instead of assuming it is a shared secret, and sending it along with the ciphertext? Well, then:

• If you encrypt it with the same key as the plaintext, you haven't really gained much security, because the effort to crack it can't be higher than the effort to brute force that key. All you've done is conceal the IV's value—which actually could be of value in some scenarios, e.g. when the IV is a counter whose value could be used to estimate how many messages have been encrypted. But that doesn't mean that encrypted IVs are more secure so much as it means that counter IVs leak information.
• If you encrypt it with a different key as the plaintext, well, now you have two keys, and the extra security comes from that. Simpler solution: use a cipher with a larger key size.