Comment by nabla9 | Hacker News Reader

Comment by nabla9 | Hacker News Reader

Parent Full thread

Obscurity is one possible layer, but it's not very good. Obscurity has a cost for anyone working with the system.

Obscurity don't scale. Things that are commonly used should not use obscurity.

Somebody who mass produces computing equipment or software that many use can't use obscurity because it's economically efficient for attackers to look past obscurity. It's also unproductive to advice others to use some obscuring methods, because as soon as something becomes even slightly common, it can be detected and security of obscurity vanishes.

Obscurity must be obscure. Great minds think alike and it's very easy to build obscurity that is similar to what everyone else thinks is nice trick.

Genuine obscurity can provides additional security layer (in probabilistic expected value sense) against automatic or routine attacks. If obscurity requires even small time to figure it out, it's likely that attacker moves to next target. But it's hard to know how well the obscurity is working.

Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.

This is interesting and quite philosophical. Is there a difference between procedures and data? Isn't it all just transistors and capcitors anyway? And is anyting really anything? Isn't it all just really quantum fields?

Practically speaking, obscurity is a "platform" that lets you bypass everything, whereas knowing a password is more limited since it grants access to a single user. But practically speaking, obscurity and root passwords are similar..

I wonder if there are formal definitions here that makes the separation clear.

If anything, I would use a lock analogy.

Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way to determine a similar safety rating for passwords/crypto based systems.

In passwords: how many passwords can you try per second before the server refuses? Then Password space/# per second = total seconds for guaranteed entry.

Crypto: how many keys do you have to calculate before you succeed in finding the correct key? Keys/second * how many machines / keyspace.

But in the end, I don't believe we really have a formalized difference between types of obscurities, aside the "go to /root and get root" obvious badness. It would be a rather nice way to provide security in "seconds to millenia depending on techniques used".

We measure password and cryptographic key security based on their entropy (keyspace) and speed (key tests / second). Given current attacks (GNFS), a 2048-bit RSA key has ~112 bits of security^1 and would take ~20,000 years to brute force using every computer ever made^2. Passwords and cryptographic keys are selected as the single point of obscurity in these systems so that many eyes may secure the other components. If the system is otherwise secure, then it is as weak as the passwords/keys which are (hopefully) picked to be very strong.

Most individuals defending algorithmic security through obscurity believe that hiding the algorithm improves security. That may be true in an extremely technical sense (the attacker must recover the algorithm first), but it is very misleading and unprofessional commentary. Algorithmic security through obscurity is at best calculated in difficulty-to-reverse-engineer (or difficulty-to-steal), which doesn't provide per-use(r) specificity (per-user password) nor scale in complexity (a 256-bit key is generally 2^128 times stronger than a 128-bit key, but doubling the algorithm length increases reversing time by slightly less than a factor of 2).

Algorithmic security through obscurity provides negligible security, but what's the harm? Why should we care? Attempting to hide the algorithm provides a false sense of security, limits review to "approved" parties, and induces legal/social efforts to "protect" the secret. The limited review is particularly noteworthy since it promotes bugs in both the algorithm and the implementation. The end result is a facade of security, some very unhappy whitehats, some very happy blackhats, and more users betrayed through poor security practices.

[1] http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_p... [2] http://tjscott.net/crypto/64bitcrack.htm#INTELG

The way I see the distinction is that obscurity is about hiding the security mechanism, whereas a key is about hiding one part of the mechanism that can be mathematically analyzed to give an estimate of how long it will take to break it.

The major difference here is this: with security through obscurity, someone can reverse engineer one product and then they've broken all products. This is why someone upstream said "security through obscurity doesn't scale". Security through obscurity is often okay if you're protecting one thing, but if you're using it to protect a system (like a pacemaker) that is going to be used by a lot of people, the more people who use it, the more valuable a reverse engineering hack becomes. Security through obscurity can't be individualized to provide security to each individual--if one system is broken all systems are broken.

Compare this with key-based security--if each instance of the system has an individual, randomized key with a large enough keyspace, breaking a key will only get you into a single instance of the system. It scales because the reward for breaking the security doesn't grow as the number of system instances grows.

Note that the problem with security through obscurity is basically the same problem with master keys, i.e. those used for backdoors or DRM. If someone can obtain the master key for the system, they can break all the instances of the system.

You can change a password, and you can calculate how hard it is to for an attacker to obtain a randomly generated password.

It is much harder to formalise how hard it is for an attacker to find out what algorithm you use, so it is risky relying too much on him not being able to do so.

Reply on news.ycombinator.com