This is the third post in a series of ten posts. The previous post analyzed Law 2: Know the Assets to Protect.

Undoubtedly, this law is one of the most famous laws of security. Unfortunately, its interpretation is too often over simplified. This law is rooted in the 19^th century. In his “la cryptographie militaire”, Auguste Kerckhoffs, a Dutch cryptographer, stated: “A [cryptographic system] must require secrecy, and should not create problems should it fall into the enemy’s hands.” In other words, the robustness of a cryptographic system should rely on the secrecy of its keys rather than on the secrecy of its algorithm. As such, a strong assumption is that if an attacker knows the algorithm used, she should gain only a minimal advantage.

Prefer known published algorithms; a
design should only use known, published, cryptographic algorithms and protocols and avoid proprietary solutions. Most recent cryptosystems, such as AES or SHA3, have been selected through a public process with the extensive scrutiny of the cryptography community. Protocols such as PKCS and TLS are public and constantly examined. And regularly vulnerabilities are reported.

Protect the key; keys are the most valuable assets in cryptography. Key management is the most critical and complicated task when designing a secure system. The symmetric keys and private keys have to be protected by all possible means. Hardware vaults such as HSM, or smart cards require more effort to be penetrated than software-based vaults,

A very common misconception about Kerckhoffs’s law is that this law mandates publishing everything, including the source code of the implementation. The implementation details are dependent on the trust model. If the trust model is similar to the model of the following figure, then open source libraries are optimal.

Unfortunately, in some contexts, the trust model looks more like the following figure. Alice cannot trust Bob. Or even, if Alice can trust Bob, she cannot trust the system on which he runs. Ruth may have compromised the system. Digital Rights Management is an example of such hostile environment

In such configuration, open source libraries are not suitable. Indeed, the attacker knows exactly where and when the secrets are handled and thus can extract them without much effort. Under these conditions, proprietary implementations are preferable. In a hostile environment, the implementation should use obfuscation techniques or white-box cryptography.

Security should never rely exclusively on obscurity. Nevertheless, obscurity may be one component of the defense. However, whenever the secret or ruse obfuscated by the obscurity is disclosed, the system should remain secure. In other words, obscurity should not be the centerpiece of the security of any system.