6
$\begingroup$

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?

Improve this question
$\endgroup$
10
  • 1
    $\begingroup$ A secret key is cheap - just take some random. A secret method is expensive - you generally need some human work. $\endgroup$
    – j.p.
    Commented Aug 14, 2012 at 9:10
  • 5
    $\begingroup$ 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. $\endgroup$
    – Maeher
    Commented Aug 14, 2012 at 9:13
  • 1
    $\begingroup$ Related question: stackoverflow.com/questions/533965/… and a paper you might find interesting: arxiv.org/abs/1109.5542 $\endgroup$
    – mikeazo
    Commented Aug 14, 2012 at 11:38
  • 1
    $\begingroup$ @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. $\endgroup$
    – Ilmari Karonen
    Commented Aug 14, 2012 at 12:10
  • 2
    $\begingroup$ The big problem with STO is this. With proper encryption, having a key compromised doesn't compromise the other keys. STO compromise = the jig is up. Just look at the reverse engineering of the original Mifare implementations. I may be wrong but the silicon of the chips was analysed and reverse engineered. That's pretty hardcore but the card encryption was left worthless. $\endgroup$
    – Shiv
    Commented Mar 24, 2016 at 2:27

5 Answers 5

Reset to default
6
$\begingroup$

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.

Improve this answer
$\endgroup$
4
6
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ 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... $\endgroup$
    – Tobias Kienzler
    Commented Aug 14, 2012 at 14:04
  • 1
    $\begingroup$ 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. $\endgroup$
    – Stephen Harris
    Commented Aug 14, 2012 at 14:14
  • 2
    $\begingroup$ @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." $\endgroup$
    – John Deters
    Commented Aug 14, 2012 at 14:49
  • $\begingroup$ @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). $\endgroup$
    – SquareRootOfTwentyThree
    Commented Aug 16, 2012 at 6:14
  • 2
    $\begingroup$ 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. $\endgroup$
    – John Deters
    Commented Aug 18, 2012 at 1:48
6
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ "the system for using the secret is completely unrelated to the secret" that seems a bit broad; surely an set of DES keys or RSA key is related to the 3DES or RSA cryptosystems respectively? Is that something you could reword? $\endgroup$
    – Maarten Bodewes ♦
    Commented Jan 6, 2022 at 21:09
5
$\begingroup$

The answer to the linked question is pretty good; however I think I'll take another approach.

In security, we need to assume that the attacker could possibly learn any secret; he might do this by attacking one of the human operators (possibly using either rubber hoses or large bags of cash), or stealing a hardware implementation and pulling it apart. Because of this, what Kerckhoffs suggested (and what we do) is divide our system into two parts:

  • One which is a long term (hard to design) cryptosystem; because it is long term, we don't assume that it is secret from the adversary for the lifetime of the system.

  • One which is a short term key; we deliberately make this easy to change, and we do so, either when we think it might be compromised, or periodically (just because).

Because the key protects only a limited amount of traffic, even if the attacker learns it, he gets access to only that amount of traffic and nothing else.

In contrast, when we say that something uses 'security by obscurity', we mean that there is something within the cryptosystem that, should the adversary learn it, severely weakens it. It may be obscure (that is, hard to learn from casual examination), however there may be leaks (even if the cryptosystem was designed perfectly). And, because it is part of the hard-to-design (and update) cryptosystem, then if the adversary does learn it, he gets access to a whole lot of traffic.

And, obviously, by the above definitions, a well-designed symmetric system is not 'security through obscurity'.

Improve this answer
$\endgroup$
1
$\begingroup$

"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

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ 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 $\endgroup$
    – Tobias Kienzler
    Commented Aug 14, 2012 at 12:44
  • 2
    $\begingroup$ @TobiasKienzler Just had to post this, xkcd.com/257 $\endgroup$
    – mikeazo
    Commented Aug 14, 2012 at 14:30
  • $\begingroup$ @mikeazo I was so hoping there was an xkcd for this :-D $\endgroup$
    – Tobias Kienzler
    Commented Aug 14, 2012 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.