From the course: Symmetric Cryptography Essential Training

Kerckhoffs's principle

From the course: Symmetric Cryptography Essential Training

Start my 1-month free trial Buy for my team

Kerckhoffs's principle

“

- [Instructor] There's this idea called Kerckhoffs's Principle, which is one of the basic assumptions in cryptography that you ought to know about. It's an important idea to cover before we start talking about any of the moving parts in symmetric and other cryptographic systems. The simplest way of stating the principle is that a systems design should not rely on secrecy. The principle is actually pretty old. In 1883, a Dutch cryptographer named Auguste Kerckhoffs published this principle in a French journal along with some other advice about securing military communications. When cryptography started becoming more of a vibrant and open academic field in the 1960s and '70s, his principle began to be incorporated into the design of modern cryptosystems. All modern, strong cryptography relies on this basic assumption. We see a similar philosophy in the free and open source software movements, which is a much larger discussion. But suffice it to say that publishing the source code of a piece of software allows more people to find bugs in it and more people can help improve it. The opposite notion to Kerckhoffs' Principle is security through obscurity, where the security of a system relies on adversaries not knowing how some part of the system works. Cryptographer Bruce Schneier in his book "Applied Cryptography", sums it up pretty well. He says, quote, "Beware of people who extol the virtues "of their algorithms, but refuse to make them public. "Trusting their algorithms "is like trusting snake oil" unquote. When a designer relies on obscurity in their cryptosystems, they're asking you to trust them even when you might not have a good reason to do so. To be fair, there are some cases where we do need obscurity in secrecy. Things like network configuration files, personally identifiable information, and what we do in the privacy of our own homes. We shouldn't expect the same obscurity in our cryptography though. But what does this look like in practice? As an analogy, here's a door. If it were a cryptosystem, we'd expect door manufacturers to make public a few things. We'd want to know how the doors are built. Is it solid wood? Are the hinges on the inside or the outside? How does the lock actually keep the door closed? We would want to know what kinds of keys the door would accept. Now that the manufacturer has published these details of their truly secure door, we can now try to figure out if there are any tricks that could let us in easily. Is the only option to open the door without a key, to smash it down with brute force? If so, we should be pretty confident that the door should only unlock with the correct key. We'll revisit the notion of brute force in cryptography in a future video. But here's my take on Kerckhoffs' Principle. The strength of a cryptosystem should rely only on the secrecy of its keys, not on keeping its inner working secret. If we keep the keys safe, we should be safe. Systems that don't conform to this may make us vulnerable. So why do cryptographers insist on this principle? As I mentioned earlier, cryptography is often the cornerstone of a comprehensive security system. We need it to work well, so cryptographers take this responsibility very seriously. For example, it's perfectly possible to reverse hardware and software to peek behind the scenes and find out how everything is actually working. Reverse engineering can be made difficult, but it cannot be made impossible. If I have access to the software or hardware, I can analyze it. Without experts reviewing a system, we don't actually know that the designer produced a secure system. And what if the designer's not quite trustworthy? If they're not, they might have built in a backdoor and are pretending that the system is secure, so that they can take advantage of you. Review by experts can catch this. And on the practical side, it's really easy to change a key if it's stolen. It's much, much harder to change out an entire algorithm if it's found vulnerable. Our systems are more secure when the experts get a chance to poke and prod at them to make sure everything works as advertised before they're actually used.

Contents