# What is the actual difference between security through obscurity and true encryption?

In an abstract sense, aren't both the same?

Don't their definitions boil down to the following?

• security through obscurity:
trying to make sure some information cannot be obtained without knowing the secret method
• encryption:
trying to make sure some information cannot be obtained without knowing the secret key

That secret method of STO is, in an abstract meaning, just a key.

So, is the actual difference that in encryption the connection between the key and the information is mathematically sound while STO uses something so abstract that attempting to describe it mathematically is not feasible and its security basically relies on that?

-
A secret key is cheap - just take some random. A secret method is expensive - you generally need some human work. – j.p. Aug 14 '12 at 9:10
One important shortcoming of security through obscurity is that there is no way to convince me that your scheme is secure without compromising its security. – Maeher Aug 14 '12 at 9:13
@Maeher that's my very question, is encryption basically proven STO with the obscurity being the secret key? – Tobias Kienzler Aug 14 '12 at 9:16
Related question: stackoverflow.com/questions/533965/… and a paper you might find interesting: arxiv.org/abs/1109.5542 – mikeazo Aug 14 '12 at 11:38
@mikeazo: Thanks, nice links! However, when linking to the arXiv, it's usually more convenient to link to the abstract page (arxiv.org/abs/1109.5542), and to drop the version number ("v1") if you don't specifically want to link to a particular version of the paper. – Ilmari Karonen Aug 14 '12 at 12:10

An analogy often given to security through obscurity vs encryption is the following: The former is hiding a letter somewhere and challenging someone to read it. The latter is picking a key from $2^{128}$ keys, locking it in a safe and challenging you to read the message. If I've understood you correctly, your question in terms of this analogy is the following: surely the 'key space' of locations is makes the letter just as secure as the lage key space of actual keys. Without any knowledge of where I've hidden the letter - surely that presents just a difficult task as if I presented you with the safe, but you didn't know which key I had used.

First of all: there is no way you can demonstrate your method of encryption is secure without revealing the method.

However there are also important conceptual differences. The method of encryption, no matter how elaborate, will never be close to random. Operations will be entirely deterministic, and leave a fingerprint on the ciphertext. The key (and often Key-IV) is what introduces (or at at least should) some degree of 'randomness'. This 'fingerprint' was what allowed British cryptographers to reverse engineer the German Lorenz machine without ever seeing it. Given enough cipher-plaintext pairs you'll be able to do this for most encryption methods.

Finally, key distribution is a problem in itself. Method distribution would be even harder. There is also the matter of the need to create lots of encryption methods - whereas generating keys is easy.

-
I think I get your point, but isn't hiding the letter the method and its location the key? And the keyspace can be quite huge if I have recently booked an around the world trip... But yes, this is not exactly encryption, since decryption requires the recipient to travel instead of simply entering a key... – Tobias Kienzler Aug 14 '12 at 13:00
But would the keyspace be larger than say, 2^128, and more importantly, are all locations equally probable? Would all locations be equally safe? If I also know something about who/what is creating these methods, I might also gleam information from that too. In the end, methods won't be truly random so won't have the same properties as a key. – Stephen Harris Aug 14 '12 at 13:11
Ah, I forgot about equal probability. That's probably the most important difference, locations to hide a letter would probably be biased by physical reachability (or its inverse). – Tobias Kienzler Aug 14 '12 at 13:19

We often mock "security through obscurity", but it is not without value, especially in today's web environment.

Most attacks today are statistical in nature: a virus attempts to infect 10,000 computers by blasting out random attacks. If it infects even two more computers out of those 10,000, it has achieved its goal.

Those viruses are aggressive in volume, not precision. They don't all do a port scan, analyze the responses to determine OS version, they don't do a vulnerability assessment, then launch a precise attack the way a human would. Instead, they try to exploit a common weakness - a buffer overrun exploit in PHP, or SQL injection vulnerability in a Wordpress plugin. Anything the system administrator does to alter their defaults: changing the base URL from "index.html" to "index.htm", or changing the database names in MySQL, might keep a particular automated attack from harming his system. It doesn't remove the vulnerability, it merely changes it so that an attack relying on the defaults will not succeed.

Will this keep out a determined attacker? Of course not. But it will reduce the number of low-level threats that can still surprise anyone if they exploit a 0day vulnerability. And those low-level threats can quickly escalate to be every bit as damaging as an Advanced Persistent Threat.

That's why obscurity, which I define here as to be "any implementation settings changed from the default", still improves your overall security picture. It may only reduce a few particular attacks, or delay them by a few days, but those days can be enough to get a real patch installed. In practice, preventing a threat from becoming a successful attack is the true job of security, regardless of whether it was based on bad theory.

-
Very good point. A former employee decreased inbound traffic a lot by simply remapping the (needed) SSH ports... I guess you agree with my comment then :-7 Of course an obscured system will be considered a more interesting challenge to the potentially more harmful intruders. Well, that's what honeypots are for... – Tobias Kienzler Aug 14 '12 at 14:04
In terms of a cryptographic system I would say the risks of potential vulnerabilities in a encryption method out weigh the benefits of keeping that method secret and out of the scrutiny of peer review (unless you're the NSA / GCHQ...). Sure obscurity can make a lazy attacker's life more difficult - but in the context of the question - it would probably make the encryption less secure. You can add obscurity by not announcing how you encrypt data - but you shouldn't rely on it as if it were security. – Stephen Harris Aug 14 '12 at 14:14
@StephenHarris, I totally agree that obscurity is not a substitute for security. However, obscurity has its place in helping reduce the risk of specific types of attack. Security is never about perfection, rather, it's about deferring a threat until it can be responded to. Think "defense in depth." – John Deters Aug 14 '12 at 14:49
@stephen-harris Side channel attacks on cryptographic systems (which are nowadays a big threat, maybe more than cryptanalysis) are based on a priori knowledge of the cryptographic algorithm. If the algorithm is secret, SCAs become a lot harder (yet not impossible). – SquareRootOfTwentyThree Aug 16 '12 at 6:14
I would stay away from the idea that keeping the algorithm secret is cryptographically an effective defense. Obscurity is a purely statistical defense, not a cryptographic defense. It's like the old joke about not having to outrun the bear, you just have to outrun the guy you're with. But once the bear has decided you're on the menu, running becomes useless as a defensive strategy. That's when you need something additional, like pepper spray, or a diversion, or a weapon. – John Deters Aug 18 '12 at 1:48

Whenever you have information to hide, something related to protecting it needs to itself be hidden. There needs to be some secret involved, and there needs to be some system of using the secret to achieve the desired security goal. The difference between the practice of keys in cryptography and Security by Obscurity is how they treat the relationship between the system and the secret.

• Security by obscurity makes the entire system the secret that needs to be protected. There is no, or very little, abstraction or differentiation between what the secret is and what the system for using the secret is. Such a scheme has a very large defense perimeter, since the system itself can be subject to attack, and cannot be changed easily to use a different secret.

• Cryptographic keys separate the system from the secret so that the system for using the secret is completely unrelated to the secret. The entire security for the system is stored in one small token. The defense perimeter is much smaller since the key itself is well-defined and reasonably small, and the secret can be easily (in theory) swapped out for another secret at will.

Strictly speaking, all security relies on some piece of information being "obscure". But be careful not to play vocabulary tricks, "security by obscurity" should not be read to mean "security using any piece of obscure information" since it has a more precise definition.

-

"Security through obscruity" is philosophical statement , its not a system on its own to be compared with encryption.

Security through obscurity means, you cannot feel/assure/guarantee security of an crypto system just by hiding the details of the crypto system .

In short , Everything about the cryptosystem should be made public except the key. Check out Kerckhoff's principle

-
Re "Everything should be made public", shouldn't that rather read "Everything becoming public should not compromise the actual encryption"? With that I mean for example a primitive rot-13-ing of an RSA encrypted message should not be considered safer than RSA alone, but it would at least keep script kiddies with a brute force cracker out for a while since they would have to find and use their brains first. And reducing the amount of potential attackers is not so bad, as is in some scenarios increasing the shortest possible attack duration – Tobias Kienzler Aug 14 '12 at 12:44
@TobiasKienzler Just had to post this, xkcd.com/257 – mikeazo Aug 14 '12 at 14:30
@mikeazo I was so hoping there was an xkcd for this :-D – Tobias Kienzler Aug 14 '12 at 15:29