“Security by obscurity” means relying on lack of knowledge of how a thing is protected as the sole means of preventing unauthorized access to that thing.
There’s been a debate going on over at the Midrange-L discussion forum about the efficacy of this approach for information security. One person in particular argues strongly that obscurity results in better security. For the most part, I disagree with this view, both philosophically and practically.
Auguste Kerckhoff, a 19th century military cryptologist, is given credit for first stating this principle of cryptography. He basically said that the security of a cryptologic system should not be based on the secrecy of the system. The secrecy of the system should rely only on the key. In other words, secrecy does not equal security.
Modern day cryptologists and security gurus — such as Bruce Schneier, author of many security books, including Applied Cryptography (considered the “bible” for computer-based cryptography implementation) — argue that Kerchoff’s axiom applies to security in general.
The argument on the forum centers around whether using a “roll-your-own-encryption” algorithm, the design of which is not publicly available, provides a greater level of security than using a well-known, well-vetted algorithm such as AES.
Don’t Do This At Home!
I just don’t believe that using a DIY algorithm results in “better security.”
First of all, if Bruce Schneier thinks security by obscurity is a bad idea, that’s good enough for me. But if that isn’t enough to convince you, the concept that “security by obscurity equals no security” makes intuitive sense, too.
Before I get into my logical proof, we need to agree on a couple of assertions.
- To date, given a certified implementation of AES, numerous math and cryptology experts have concluded that it is mathematically impossible to decrypt encrypted data without the encryption key other than by brute-force. .
- Inventing a new encryption algorithm that meets the “mathematically impossible” standard is very hard. On the difficulty scale it is right up there with rocket science!
- The vast majority of IT shops do not have the expertise required to invent an encryption algorithm that meets the mathematically impossible standard.
Your DIY Encryption Algorithms Aren’t Even Obscure
While I have thought through several logical proofs to support the axiom, I think the most easily grasped argument against security by obscurity is this:
- Getting access to executable code is relatively easy.
Hopefully, there is no argument with this. I mean, if it were possible to prevent access to computer programs, it should also be possible to prevent access to unencrypted data. That’s the very reason that more and more data is required to be encrypted! - If you have access to executable code, de-compiling it to assembler level code is relatively easy.
I know that de-compilers exist for power system CPUs. - Analyzing assembler code to understand the algorithm it implements is relatively easy.
Again, I know from personal (painful) experience that this isn’t hard to do. - Therefore, any encryption algorithm implemented in a computer program is assumed to be “unobscured. “
In this particular case, it doesn’t make sense to use a “roll-your-own-encryption” algorithm. Any algorithm you implement in your code is publicly documented. Thus you can’t rely on your algorithm actually being obscure. If the algorithm can’t be obscured, then the best level of security is gained by using a well-known, well-understood, well-vetted, publicly available algorithm that is considered to be mathematically impossible to break.
Secrecy ≠ Security
I believe, however, that the “security by obscurity” axiom holds true in the general case for more important reasons. As Schneier says, relying on the secrecy of a system makes it more brittle. More readily breakable. If we need to encrypt data at rest on our systems in order to keep the data secret (i.e. prevent unauthorized access), then neither we can’t hope to keep secret the security mechanisms implemented on the same system and used to protect that data.
It is important, however, to understand that just because you can’t rely on the secrecy of the methods you use to protect your data, that doesn’t mean that it’s a good idea to publicly broadcast the methods you use. For example, there is no need to put on your web site “We use 1024-bit AES encryption in block-cipher mode.” Making this information public doesn’t significantly reduce your level of security. But if there is no business reason to do so, don’t put it on the page! You might deter a few casual hackers, but your real concern is determined hackers.
Know Your Security Risk
One final thought. Security is about reducing risk. Nothing is absolutely infallible. Risk cannot be reduced to zero. Real security management should be based on quantifying your level of risk before and after implementing encryption and comparing the two values. The lower the “after implementation” relative to the “before implementation” risk, the better the return on your investment.
Using a well-known, publicly available algorithm provides a quantifiable level of risk. Unless you engage several math and cryptology experts to review your own algorithm, it is not possible to quantify the level of risk inherent in your algorithm. Therefore, there is no way to make a rational business decision about the efficacy of a roll-your-own encryption algorithm.
The Bottom Line
So, whether you use a well-known algorithm or a roll-your-own algorithm, it is essentially impossible to keep secret which method you are using. Using a roll-your-own algorithm requires you to accept an unknown amount of risk. Using a well-known algorithm allows you to understand the level of risk you are accepting. And because — contrary to popular opinion, perhaps — “security” is really a risk management proposition, only the well-understood algorithms allow you to make a rational decision.
