Kerckhoffs's principle

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

In cryptography, Kerckhoffs's principle (also called Kerckhoffs's desiderata, Kerckhoffs's assumption, axiom, or law) was stated by Auguste Kerckhoffs in the 19th century: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Kerckhoffs's principle was reformulated (or perhaps independently formulated) by Claude Shannon as "the enemy knows the system", [1] i.e., "one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them". In that form, it is called Shannon's maxim. In contrast to "security through obscurity", it is widely embraced by cryptographers.

Origins

In 1883 Auguste Kerckhoffs[2] wrote two journal articles on La Cryptographie Militaire,[3] in which he stated six design principles for military ciphers. Translated from French, they are:[4]

  1. The system must be practically, if not mathematically, indecipherable;
  2. It should not require secrecy, and it should not be a problem if it falls into enemy hands;
  3. It must be possible to communicate and remember the key without using written notes, and correspondents must be able to change or modify it at will;
  4. It must be applicable to telegraph communications;
  5. It must be portable, and should not require several persons to handle or operate;
  6. Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules.

Some are no longer relevant given the ability of computers to perform complex encryption, but his second axiom, now known as Kerckhoffs's principle, is still critically important.

Explanation of the principle

Stated simply, the security of a cryptosystem should depend solely on the secrecy of the key and the private randomizer.[5] Another way of putting it is that a method of secretly coding and transmitting information should be secure even if everyone knows how it works. Of course, despite the attacker's familiarity with the system in question, the attacker lacks knowledge as to which of all possible instances is being presently observed.

Advantage of secret keys

Using secure cryptography is supposed to replace the difficult problem of keeping messages secure with a much more manageable one, keeping relatively small keys secure. A system that requires long-term secrecy for something as large and complex as the whole design of a cryptographic system obviously cannot achieve that goal. It only replaces one hard problem with another. However, if a system is secure even when the enemy knows everything except the key, then all that is needed is to manage keeping the keys secret.

There are a large number of ways the internal details of a widely used system could be discovered. The most obvious is that someone could bribe, blackmail, or otherwise threaten staff or customers into explaining the system. In war, for example, one side will probably capture some equipment and people from the other side. Each side will also use spies to gather information.

If a method involves software, someone could do memory dumps or run the software under the control of a debugger in order to understand the method. If hardware is being used, someone could buy or steal some of the hardware and build whatever programs or gadgets needed to test it. Hardware can also be dismantled so that the chip details can be seen with microscopes.

Maintaining security

A generalization some make from Kerckhoffs's principle is: "The fewer and simpler the secrets that one must keep to ensure system security, the easier it is to maintain system security." Bruce Schneier ties it in with a belief that all security systems must be designed to fail as gracefully as possible:

<templatestyles src="Template:Blockquote/styles.css" />

Kerckhoffs's principle applies beyond codes and ciphers to security systems in general: every secret creates a potential failure point. Secrecy, in other words, is a prime cause of brittleness—and therefore something likely to make a system prone to catastrophic collapse. Conversely, openness provides ductility.[6]

Any security system depends crucially on keeping some things secret. However, Kerckhoffs's principle points out that the things kept secret ought to be those least costly to change if inadvertently disclosed.

For example, a cryptographic algorithm may be implemented by hardware and software that is widely distributed among users. If security depends on keeping that secret, then disclosure leads to major logistic difficulties in developing, testing, and distributing implementations of a new algorithm – it is "brittle". On the other hand, if keeping the algorithm secret is not important, but only the keys used with the algorithm must be secret, then disclosure of the keys simply requires the simpler, less costly process of generating and distributing new keys.

Applications

In accordance with Kerckhoffs's principle, the majority of civilian cryptography makes use of publicly known algorithms. By contrast, ciphers used to protect classified government or military information are often kept secret (see Type 1 encryption). However, it should not be assumed that government/military ciphers must be kept secret to maintain security. It is possible that they are intended to be as cryptographically sound as public algorithms, and the decision to keep them secret is in keeping with a layered security posture.

Security through obscurity

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

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.

Steve Bellovin commented:

<templatestyles src="Template:Blockquote/styles.css" />

The subject of security through obscurity comes up frequently. I think a lot of the debate happens because people misunderstand the issue.

It helps, I think, to go back to Kerckhoffs's second principle, translated as "The system must not require secrecy and can be stolen by the enemy without causing trouble," per http://petitcolas.net/fabien/kerckhoffs/). Kerckhoffs said neither "publish everything" nor "keep everything secret"; rather, he said that the system should still be secure even if the enemy has a copy.

In other words – design your system assuming that your opponents know it in detail. (A former official at NSA's National Computer Security Center told me that the standard assumption there was that serial number 1 of any new device was delivered to the Kremlin.) After that, though, there's nothing wrong with trying to keep it secret – it's another hurdle factor the enemy has to overcome. (One obstacle the British ran into when attacking the German Enigma system was simple: they didn't know the unkeyed mapping between keyboard keys and the input to the rotor array.)

But – don't rely on secrecy.[7]

Notes

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found. p.235
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Auguste Kerckhoffs, "La cryptographie militaire" Journal des sciences militaires, vol. IX, pp. 5–83, January 1883, pp. 161–191, February 1883.
  5. Lua error in package.lua at line 80: module 'strict' not found. p.2.5
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.

References

This article incorporates material from the Citizendium article "Kerckhoffs' Principle", which is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License but not under the GFDL.

External links