Kerckhoffs’ principles – Why should I make my cipher public?

Question

As I understand it, the less people know about the internals of my protocol or cipher, the more secure the protocol is. However Kerckhoffs's principle states that

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

To be more precise, it's the 2nd principle that states

It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;

Of course I understand why I should keep the key secret, but publishing my protocol's internals seems counter-intuitive. Why should I do it? Wouldn't that give the advantage to the attacker?

Answer 1

Actually, that wikipedia article you mention in your question already answers your question:

It is moderately common for companies and sometimes even standards bodies as in the case of the CSS encryption on DVDs – to keep the inner workings of a system secret. Some argue this "security by obscurity" makes the product safer and less vulnerable to attack. A counter argument is that keeping the innards secret may improve security in the short term, but in the long run only systems that have been published and analyzed should be trusted.

But let's dive in deeper anyway...

Kerckhoffs’ principles

For reference purposes, here is Kerckhoffs' original text (from Auguste Kerckhoffs, "La cryptographie militaire", Journal des sciences militaires, vol. IX, pp. 5–38 "II. DESIDERATA DE LA CRYPTOGRAPHIE MILITAIRE.", Jan. 1883):

In plain text, this reads:

1° Le système doit être matériellement, sinon mathématiquement, indéchiffrable ;
2° Il faut qu’il n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi ;
3° La clef doit pouvoir en être communiquée et retenue sans le secours de notes écrites, et être changée ou modifiée au gré des correspondants ;
4° Il faut qu’il soit applicable à la correspondance télégraphique ;
5° Il faut qu’il soit portatif, et que son maniement ou son fonctionnement n’exige pas le concours de plusieurs personnes ;
6° Enfin, il est nécessaire, vu les circonstances qui en commandent l’application, que le système soit d’un usage facile, ne demandant ni tension d’esprit, ni la connaissance d’une longue série de règles à observer.

And here is my English translation for your convenience:

1. The system must be physically, if not mathematically, indecipherable;
2. It must not require secrecy, and may not cause inconveniences when it falls into the hands of the enemy;
3. The key must be communicated and retained without the aid of written notes, and be changed or modified at the discretion of correspondents;
4. It must be applicable to telegraphic correspondence;
5. It must be portable, and its usage and its operation does not require the assistance of several people;
6. Finally, it is necessary, given the circumstances that control the application, that the system is easy to use, requiring no mental strain, or the knowledge of a long series of rules to be observed.

The enemy knows the system

Kerckhoffs' surviving principle nr. 2 (of initially six design principles for military ciphers) says nothing else than that you have to look at the security of your crypto under the aspects of "the enemy knows the algorithm" and maybe even "the enemy carries the message". The well-known Claude Shannon once simplified Kerckhoffs' principle as: "the enemy knows the system".

The "advantage to the attacker" one might be thinking about when deciding to keep an algo secret, would practically be "just a matter of time for the attacker to find out" since keeping the algorithm secret would be relying on "security through obscurity", which we all know to be a bad idea.

The idea of Kerckhoffs' principle is that if any part of a cryptosystem (except the individual secret key) has to be kept secret then the cryptosystem is not secure. That's because, if the simple act of disclosing some detail of the system were to make it suddenly insecure, then you've got a problem on your hands. The gold standard for any secret keeping system is that all its details should be able to be made public without compromising the security of the system. The security relies on the system itself, not the secrecy of the system.

A good example of why Kerckhoffs' principle makes sense would be the German Enigma machine used in WWII. By stealing machines, the Allies knew everything there was to know about how the Enigma machine worked; they only had to read the manuals, use the code-books and look at the way the machine was constructed and worked. After all, they had a working example in their hands. Throughout history, there are countless examples of secret algorithms falling into wider knowledge, variously through espionage, betrayal and reverse engineering. And on occasion, ciphers have been reconstructed through pure deduction. For example, the German Lorenz cipher and the Japanese Purple code, and a variety of classical schemes.

Therefore, the core idea of Kerckhoffs' 2nd principle is still applied today. The security of HTTPS, SSL and ciphers like AES or RSA rely on the strength of the algorithm, not on keeping them secret. The algorithms are all published and detailed standards have been created which everyone can take a look at. The only "secret" is the key that's chosen when you connect to a secure web site (that's done automatically and randomly by your browser and the server) or when you encrypt a document using a program like GPG.

To recap: why publish the cryptographic algorithm?

Not publishing a cryptographic algorithm doesn’t make much sense as it's just a matter of time for the attacker to find out how your crypto works. Security gain can therefore only be of temporary nature.

On the other hand, publishing of a cryptographic algorithm tends to build trust because the publication of its internals allows the verification of related security claims.

In fact, you can even transport the answer to “why publish the cryptographic algorithm” down to a much simpler level: the security of the lock of your home's door does not depend on keeping the lock hidden and its mechanisms secret. Its security comes from you keeping the key safe. That is one of the most simple examples of Kerckhoffs' 2nd principle in action.

One of many examples

To provide an example, let me point you to — what I would call — an "über-publication": "The Design of Rijndael: AES - The Advanced Encryption Standard" by Joan Daemen and Vincent Rijmen.

This book, written by the designers of the block cipher, presents Rijndael (more commonly known as AES) from scratch. The underlying mathematics and the wide trail strategy as the basic design idea are explained in detail and the basics of differential and linear cryptanalysis are reworked. Subsequent chapters review all known attacks against the Rijndael structure and deal with implementation and optimization issues. Finally, other ciphers related to Rijndael are presented.

As you might have noticed: it didn't hurt the security of Rijndael/AES in any way that all its internals were published. Quite the contrary – related publications only resulted in more confidence in the cipher.

Answer 2

This is actually to a great extent a question of terminology, and ultimately which security claims you are prepared to make, more than it is a practical question.

For short: You may draw the line between the key space and the algorithm any way you want, but the way you draw that line will have implications regarding which security claims you are able to justify. Consequently, in order to be coherent, you might just as well put as much into the algorithm category (instead of the key category), as possible without having to lower the security claims you are actually able to justify.

Nothing prevents you from defining your terms in such way, that the instructions that make up your system, are considered part of the key, rather than part of the algorithm, and consequently are to be kept secret.

Consequently, if you e.g. have a block cipher with a 128 bit block size, reveal no information about the instructions that make up your block cipher, and claim that no adversary is able to determine anything about these instructions, you are essentially claiming that your block cipher is an ideal random permutation of $\{0,1\}^{128}$, which means that the key space is as large as $2^{128}!$ (which, just to be clear, is exponentially more than $2^{128}$).

However, no man-made circuit will ever be able to implement a block cipher with a $2^{128}!$ key space, so it will be possible for someone analyzing your black box, to establishing an upper bound of the number of instructions your algorithm realistically executes and of how much memory it realistically has available. If you have actually claimed that your "algorithm" is completely secret, this is enough to prove that your (implicit) security claims are false, and hence that your algorithm is broken.

Answer 3

When publishing the algorithm other people can review your algorithm and design.

With this they can find flaws in your design and therefore improve this.

The principle behind this is simply that many eyes find more errors than two eyes.

Why do you think does the NIST review new candidates for cipher suites (AES)? This is to improve the security by having many people look at it.

Many crypto algorithms that were secured by obscurity are insecure. Most don't even have a name.

So a good cryptographic algorithm draws it security from the key and not from an obscured algorithm.

Answer 4

Basically, yes, you should make your cipher public, because (1) it is the only way that anyone else will trust it, and (2) it is the only way to find out if your cipher is possibly worthy of trust.

Bruce Schneier's Memo to the Amateur Cipher Designer has a reasonable summary/explanation of the standard arguments. Don't miss this part:

"Anyone [..] can create an algorithm that he himself can't break. What is hard is creating an algorithm that no one else can break. [..] And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around."

Schneier then goes on to explain how you need to publish the cipher, to have a chance that the world's best cryptographers take a look at it (if you don't publish the cipher, it's very unlikely they will look at it, and thus no one will have any basis to trust your cipher).

Answer 5

An algorithm which is secure even if the enemy acquires everything but the key may be regarded as a means of generating secure algorithms. If one presently has a secure channel for communicating with a correspondent, and will need to communicate securely in future when no secure channel is available, using some dice to generate a random key and conveying it to the correspondent will effectively establish a new method of encrypted communication for use with that correspondent. That's much easier than trying to formulate a new algorithm from scratch.

As for what's wrong with keeping the algorithm secret, the fundamental argument against that is that working with something that needs to be kept secret is more bother than working with something that can be considered public. Guarding the algorithm well enough to prevent its discovery would likely require a lot more effort than it's worth; guarding it "almost" well enough would require just as much effort and be worth almost nothing. It's much easier and more practical to simply not worry about guarding it.

Answer 6

Actually publishing your cipher will also be able to give you a lot of feedback. An actual end-user's opinions you will be able to collect without it, but your potential users' opinion are sometimes priceless.